4 ms·

> many software developers simply stopped caring about performance... Little "conspiracy" theory here if you can call it that, and not one that a lot of people

> many software developers simply stopped caring about performance... Little "conspiracy" theory here if you can call it that, and not one that a lot of people will agree with I imagine, but I sometimes think this was caused by the mass adoption of "premature optimisation is the root of all evil". The problem is, for a lot of devs, quite possibly myself included, its either premature or an afterthought. With mass adoption of that phrase, it becomes an afterthought. For me, for better or worse, I can't get out of it. It doesn't mean I never write inefficient software, especially in my day job I come into conflict with that, but its always the first thing in my mind. Maybe I'm way off base there and just trying to justify bad habits, but I can't say it feels bad to me.

MaulingMonkey 5y ago
Premature optimization is time spent not optimizing things that actually matter. In my own circles, it's the accusation legitimately levied against the clowns who simultaniously write macros instead of functions out of fears that the compiler could theoretically ignore a __forceinline keyword - or if you're lucky, optimizing some microbenchmark while pessimizing overall program performance - and in the next breath writing O(scary) code that'll be invoked with large enough N to demolish any savings from micro-optimizations. That is, despite optimizing, these are people who, despite an obsession with performance, are still treating the performance of their overall programs as an afterthought. Because they don't actually care about performance as much as they say: they care about showing off and flexing their coding skills by making a mess. Well, the phrase itself doesn't help guide these people towards real performance engineering, but they're typically stubborn enough to ignore the phrase, and must instead be goaded into using a profiler or generating benchmarks, which can then be picked apart when they optimize away the actual execution of everything at compile time, teaching by way of concrete example at least a little bit about generating better microbenchmarks, which they can use to show off and flex more effectively instead.
- liveoneggs 5y ago
  > are still treating the performance of their overall programs as an afterthought Because that is harder to test
- bodge5000 5y ago
  That doesnt sound like premature optimisation to me. A problem certainly, but premature optimisation should be exactly what it sounds like; optimising something before it needs optimisation. Or perhaps it frequently manifests in that way, but I wouldnt say thats what it is. I know that in my case its much more general, usually because my approach (when Im working on personal projects of course) to optimisation is to change the approach rather than change the code. As you say, overly optimised code is difficult to read and maintain, which in my view is a problem of optimisation itself, so I just try to find compromise and do something thats more efficient. But I'd still call that premature optimisation, because its rarely triggered by a problem.
AnIdiotOnTheNet 5y ago
Honestly you don't even have to think about optimization to make your software not horrifically slow on modern hardware, instead you have to think about non-pessimization. Simply put, avoid needless complexity and gratuitous waste in the first place. See Refterm Lecture Part 1 - Philosophies of Optimization by Casey Muratori: https://youtu.be/pgoetgxecw8 https://youtu.be/pgoetgxecw8
- bodge5000 5y ago
  Oh absolutely, you can write perfectly fine software just by being considerate to what you're writing and never have to even consider optimisation. This is one area where premature optimisation becomes a problem for me; I know this, and I prematurely optimise anyway (though I am working turning that down a bit). For me, another widely held belief (although far less so than the root of all evil) is also somewhat the cause of this problem, particularly the issues you're talking about, this idea that if a library exists for something you shouldnt waste time rewriting it, which ends up with projects stacked to the brim with dependencies. Of course sometimes it is more efficient to use a library, I don't intend to rewrite perlin noise for example, but it shouldnt be your first choice I don't think.

MaulingMonkey 5y ago

Premature optimization is time spent not optimizing things that actually matter. In my own circles, it's the accusation legitimately levied against the clowns who simultaniously write macros instead of functions out of fears that the compiler could theoretically ignore a __forceinline keyword - or if you're lucky, optimizing some microbenchmark while pessimizing overall program performance - and in the next breath writing O(scary) code that'll be invoked with large enough N to demolish any savings from micro-optimizations. That is, despite optimizing, these are people who, despite an obsession with performance, are still treating the performance of their overall programs as an afterthought. Because they don't actually care about performance as much as they say: they care about showing off and flexing their coding skills by making a mess. Well, the phrase itself doesn't help guide these people towards real performance engineering, but they're typically stubborn enough to ignore the phrase, and must instead be goaded into using a profiler or generating benchmarks, which can then be picked apart when they optimize away the actual execution of everything at compile time, teaching by way of concrete example at least a little bit about generating better microbenchmarks, which they can use to show off and flex more effectively instead.

liveoneggs 5y ago
> are still treating the performance of their overall programs as an afterthought Because that is harder to test
bodge5000 5y ago
That doesnt sound like premature optimisation to me. A problem certainly, but premature optimisation should be exactly what it sounds like; optimising something before it needs optimisation. Or perhaps it frequently manifests in that way, but I wouldnt say thats what it is. I know that in my case its much more general, usually because my approach (when Im working on personal projects of course) to optimisation is to change the approach rather than change the code. As you say, overly optimised code is difficult to read and maintain, which in my view is a problem of optimisation itself, so I just try to find compromise and do something thats more efficient. But I'd still call that premature optimisation, because its rarely triggered by a problem.

AnIdiotOnTheNet 5y ago

Honestly you don't even have to think about optimization to make your software not horrifically slow on modern hardware, instead you have to think about non-pessimization. Simply put, avoid needless complexity and gratuitous waste in the first place. See Refterm Lecture Part 1 - Philosophies of Optimization by Casey Muratori: https://youtu.be/pgoetgxecw8 https://youtu.be/pgoetgxecw8

bodge5000 5y ago
Oh absolutely, you can write perfectly fine software just by being considerate to what you're writing and never have to even consider optimisation. This is one area where premature optimisation becomes a problem for me; I know this, and I prematurely optimise anyway (though I am working turning that down a bit). For me, another widely held belief (although far less so than the root of all evil) is also somewhat the cause of this problem, particularly the issues you're talking about, this idea that if a library exists for something you shouldnt waste time rewriting it, which ends up with projects stacked to the brim with dependencies. Of course sometimes it is more efficient to use a library, I don't intend to rewrite perlin noise for example, but it shouldnt be your first choice I don't think.