Comment by fabian2k
6 hours ago
I think people tend to overestimate how much certain choices matter for performance. But I don't agree that the speed of frameworks doesn't matter in most cases. To me the base performance of such a framework is essentially like a leaky abstraction. The moment I hit any bottleneck I suddenly need to understand how the framework works internally to work around it.
I'm unlikely to get bottlenecked on well written and idiomatic code in a slower framework. But I'm much more likely to accidentally do something very inefficient in such a framework and then hit a bottleneck.
I also think the difference in ergonomics and abstraction are not that huge between "slow" and "fast" frameworks. I don't think ASP.NET Core for example is significantly less productive than the web frameworks in dynamic languages if you know it.
I think the problem with optimization as an approach to getting a program to be fast is that it's fairly often not bottlenecks that are the problem, but architectural choices that don't show up in the profiler's flame charts.
Even if you find a slow function that constitutes 20% of the runtime, and optimize the living hell out of it to cut out 20% of the execution time, guess what your program is now about 4.1% faster.