4 ms·

I agree fully. Speed matters. Too many people consider CPU time too cheap to consider. I still marvel at how fast and efficient could Symbian OS be on a 190 MHz

I agree fully. Speed matters. Too many people consider CPU time too cheap to consider. I still marvel at how fast and efficient could Symbian OS be on a 190 MHz Nokia. (Though the API was hell.) That said, it is also true that premature optimization is the root of all evil. I suspect programming wisdom hides somewhere in between those two hills, neither of which is worth dying on.

rockwotj 2y ago
Yeah be data driven and optimize the hot data path, the other code paths optimize for simplicity (and the majority of a system is the latter)
hansvm 2y ago
That's an interesting point as well, but the entire article seems to me to be focused on programmer speed rather than program speed. What about it spoke to the latter rather than the former for you?
- inglor_cz 2y ago
  Specifically the SQLite release statement. Quite recently, I did the same in my code, fishing for many micro-optimizations that sped up the execution by 1 per cent or so. These added up nicely.
Aurornis 2y ago
Well the article is about speed of development, not the speed at which the code runs. Over the years I’ve come to embrace moving fast and writing code quickly, even if it’s not the fastest. The faster I get the big things done, the more time I can spend optimizing what matters after I’ve identified it and determined it’s valuable.
- inglor_cz 2y ago
  There is an overlap. Writing for PHP, I used to spend a lot of time waiting for Xdebug to trigger. Once the author released version 3.3, the improvement was so big that my own productivity went visibly up.
- branko_d 2y ago
  On the other hand, some of the biggest performance wins come from the architectural choices, and those are often done before most of the code is written.
  - whstl 2y ago
    Yep, same experience. "Some of the biggest performance wins" in both developer speed and processing speed.
tmtvl 2y ago
> premature optimization is the root of all evil. Yeah, we should forget about small efficiencies, say about 97% of the time. Yet we should not pass up our opportunities in that critical 3%.

rockwotj 2y ago

Yeah be data driven and optimize the hot data path, the other code paths optimize for simplicity (and the majority of a system is the latter)

hansvm 2y ago

That's an interesting point as well, but the entire article seems to me to be focused on programmer speed rather than program speed. What about it spoke to the latter rather than the former for you?

inglor_cz 2y ago
Specifically the SQLite release statement. Quite recently, I did the same in my code, fishing for many micro-optimizations that sped up the execution by 1 per cent or so. These added up nicely.

Aurornis 2y ago

Well the article is about speed of development, not the speed at which the code runs. Over the years I’ve come to embrace moving fast and writing code quickly, even if it’s not the fastest. The faster I get the big things done, the more time I can spend optimizing what matters after I’ve identified it and determined it’s valuable.

inglor_cz 2y ago
There is an overlap. Writing for PHP, I used to spend a lot of time waiting for Xdebug to trigger. Once the author released version 3.3, the improvement was so big that my own productivity went visibly up.
branko_d 2y ago
On the other hand, some of the biggest performance wins come from the architectural choices, and those are often done before most of the code is written.
- whstl 2y ago
  Yep, same experience. "Some of the biggest performance wins" in both developer speed and processing speed.

tmtvl 2y ago

> premature optimization is the root of all evil. Yeah, we should forget about small efficiencies, say about 97% of the time. Yet we should not pass up our opportunities in that critical 3%.