3 ms·

> should be discouraged. If you need to read in 1M integers, put them in a file and read them in. This is exactly the attitude that needs to be addressed. It's

by titzer 3y ago

> should be discouraged. If you need to read in 1M integers, put them in a file and read them in. This is exactly the attitude that needs to be addressed. It's hostile to argue with users who are doing something completely legal and tell them they shouldn't do that, they should do it another way, that that behavior needs to be discouraged, etc. We went through this all the time with V8, trying to tell JS developers they just shouldn't do that because V8 had couldn't run that code fast. Or worse, that it had a particular pathology that made certain code absurdly slow. It just doesn't fly. It's V8's job to not go off the rails for user inputs; it should provide good default performance all the time, not get stuck in deopt loops, use absurd amounts of memory, etc. Yeah, and that's hard work.

turnsout 3y ago
I hear you, ideally the compiler should be able to manage any arbitrary input in a reasonable time, and catch itself if necessary. Usually it does—sometimes with complex ungrouped arithmetic operations with ambiguous types, Swift will error out and tell you to break up your expression, rather than get stuck. I would love for the Swift compiler to be dramatically faster, but I understand the challenge, with a powerful type inference engine that supports Generics. It's a resource scarcity problem. If the Swift team spends 10 hours to handle long strings of integer literals, that's 10 hours they haven't put toward features that would benefit a larger audience.
- ihatejs 3y ago
  Your take sounds more reasonable. I would think you would get diminishing returns if you try to solve all pathological cases. Sometimes it is the fault of the language design too. Maybe the language spec needs to be changed. Imagine all the wasted effort to optimize V8 when you could have put static typing into Javascript itself.
  - turnsout 3y ago
    Indeed—Chris Lattner has mentioned recently that in retrospect, he regrets certain Swift design decisions which have made the compiler so complex and relatively slow.

by titzer 3y ago

turnsout 3y ago

I hear you, ideally the compiler should be able to manage any arbitrary input in a reasonable time, and catch itself if necessary. Usually it does—sometimes with complex ungrouped arithmetic operations with ambiguous types, Swift will error out and tell you to break up your expression, rather than get stuck. I would love for the Swift compiler to be dramatically faster, but I understand the challenge, with a powerful type inference engine that supports Generics. It's a resource scarcity problem. If the Swift team spends 10 hours to handle long strings of integer literals, that's 10 hours they haven't put toward features that would benefit a larger audience.

ihatejs 3y ago
Your take sounds more reasonable. I would think you would get diminishing returns if you try to solve all pathological cases. Sometimes it is the fault of the language design too. Maybe the language spec needs to be changed. Imagine all the wasted effort to optimize V8 when you could have put static typing into Javascript itself.
- turnsout 3y ago
  Indeed—Chris Lattner has mentioned recently that in retrospect, he regrets certain Swift design decisions which have made the compiler so complex and relatively slow.