3 ms·

We went from ”premature optimization is evil” to ”optimization is evil”

by nikanj 4y ago

zweifuss 4y ago
Having a list of all audio recordings always shown on the right pane is kinda an optimization (VoiceRecorder.exe). The usefulness is limited, because VoiceRecorder can't edit them, only play back and set markings.
shrimpx 4y ago
An alternate view is that the state of program optimization is terrible.
- kaba0 4y ago
  Well, optimizations need good abstractions to work with. The reason why a SQL query can run much faster than a naive for loop would is precisely due to SQL being very removed from lower-level details. So in extension, optimization is terrible because we might be using the wrong abstraction level? E.g. it is hard to optimize a larger JS program, because if the developer specified some sort of detail it might throw out an entire class of possible optimizations. There is actually an interesting presentation on the topic here: https://news.ycombinator.com/item?id=9396950 https://news.ycombinator.com/item?id=9396950 , which discusses among others whether a two-way communication between compiler and developer may help.
Cthulhu_ 4y ago
I don't think either is true. I think it's a case of "development by committee" - many different people work on a codebase, but nobody is critical enough of the whole product. I can imagine the audio recorder is a low priority minor side project that gets handed from one guy (or team) to the next every couple of years, with the emphasis on "don't spend too much time on it". The other issue is that performance is taken for granted; if something is slow, it's not immediately obvious.
- Falkon1313 4y ago
  For sure. But not just "development by committee" also "development by hundreds of unrelated committees". By which of course I mean the full stack of dependencies that everything relies upon now, along with all the glue code in between that has to repeatedly transform data as it gets passed around through the system. I've often seen some dependency module be the bottleneck, and an in-house replacement that does just what we need can perform an order of magnitude or two better than a generic 'all things for all people' module. Also there are things that work well for dozens or hundreds of data pieces but become abysmal when you eventually scale to hundreds of thousands. But no one else has that use case, so it works fine for them. And for those that do, by then the frog is boiled and they're used to it being slow.
dusted 4y ago
yea, we went from being burned by trying to optimize before we knew the problem, to being burned by not optimizing because we knew the problem but didn't optimize.

We went from ”premature optimization is evil” to ”optimization is evil”

by nikanj 4y ago

We went from ”premature optimization is evil” to ”optimization is evil”

Having a list of all audio recordings always shown on the right pane is kinda an optimization (VoiceRecorder.exe). The usefulness is limited, because VoiceRecorder can't edit them, only play back and set markings.

shrimpx 4y ago

An alternate view is that the state of program optimization is terrible.

kaba0 4y ago
Well, optimizations need good abstractions to work with. The reason why a SQL query can run much faster than a naive for loop would is precisely due to SQL being very removed from lower-level details. So in extension, optimization is terrible because we might be using the wrong abstraction level? E.g. it is hard to optimize a larger JS program, because if the developer specified some sort of detail it might throw out an entire class of possible optimizations. There is actually an interesting presentation on the topic here: https://news.ycombinator.com/item?id=9396950 https://news.ycombinator.com/item?id=9396950 , which discusses among others whether a two-way communication between compiler and developer may help.

Cthulhu_ 4y ago

I don't think either is true. I think it's a case of "development by committee" - many different people work on a codebase, but nobody is critical enough of the whole product. I can imagine the audio recorder is a low priority minor side project that gets handed from one guy (or team) to the next every couple of years, with the emphasis on "don't spend too much time on it". The other issue is that performance is taken for granted; if something is slow, it's not immediately obvious.

Falkon1313 4y ago
For sure. But not just "development by committee" also "development by hundreds of unrelated committees". By which of course I mean the full stack of dependencies that everything relies upon now, along with all the glue code in between that has to repeatedly transform data as it gets passed around through the system. I've often seen some dependency module be the bottleneck, and an in-house replacement that does just what we need can perform an order of magnitude or two better than a generic 'all things for all people' module. Also there are things that work well for dozens or hundreds of data pieces but become abysmal when you eventually scale to hundreds of thousands. But no one else has that use case, so it works fine for them. And for those that do, by then the frog is boiled and they're used to it being slow.

dusted 4y ago

yea, we went from being burned by trying to optimize before we knew the problem, to being burned by not optimizing because we knew the problem but didn't optimize.