2 ms·
It seems many comments in this thread don't get the point. The "Premature Optimization is Root of all Evil" is about juvenile low level optimizations that sacr
by terminaljunkid 7y ago
It seems many comments in this thread don't get the point.
The "Premature Optimization is Root of all Evil" is about juvenile low level optimizations that sacrifice code readability. They don't give high perf gains either.
But that doesn't mean "Don't think at all about performance in beginning, you can optimize later". That's bullshit notion. Someone will end up paying in AWS bills for that. For instance, every programmer should know how latency varies between disk and memory access, and think about the tradeoffs at design/spec level.
It is true that there are cases where even that doesn't matter. But in most cases where people think so, It ends up they pay double in AWS bills to save two hours of thinking.
- fraktl 7y agoNo, many DO get the point. Point is that decision-making isn't binary. If I have a form and UI that collects the data, of course I won't try to use enums and weak maps or "the fastest client side framework" to succeed in the actual task: collect and save data. Before business logic is known, you can't design for performance. That's why "Premature optimization is the root of all evil exists". Now, if you design for performance - that means you KNOW something ahead, and there's less discovery involved. I'm not sure why people have the desire to create lists or rules for tasks whose workloads are unknown. We all want to get beautiful code paired with performance and features. But before we know what we have to achieve, it's hard and dangerous to focus on performance only. I never adhered to hard rules or thoughts from people that think binary-only. Every situation requires analysis before action can be taken. Therefore, the right tool for the job is my mantra and this "article" is extremely dangerous since it's tunnel-visioned.