A lot of my poor opinion on developer opinions dates back to a couple projects where Product and Marketing were begging us for substantial performance improvements and the teams pushed back saying this was as fast as you could expect. I got 2x in the first six months on both projects, and delivered 25% per quarter on one for almost 2 years (that maths to around 8x) before I started to scrape the bottom of my barrel.
It’s predominantly a way to shut down thinking, which is why it’s so often misquoted. Knuth’s version is more nuanced. Theirs is not at all.
As a compromise I got really good at doing optimizations that also improved readability. Things like hoisting and better variable naming combined together can be mistaken for just code cleanup.
I also discovered that keyhole optimizations are more palatable. Which is to say, move the slow bit yo a separate function with a single responsibility. Then do the optimization in a separate commit. Then the other devs don’t have to look at your changes and if they turn out to have a bug, we can always revert the change later. They almost never do, but having the option seems to grease the wheels.
My general rule of thumb is that if you see you can 2x it easily, you can actually get somewhere around 10x with effort, since the presence of that easy 2x means nobody really spent any time on performance.
i got over 800 this way. O(n^2) everywhere and n+1 queries
It can go to extremes. Like 100x by going from a dynamic to static language then 100x more adjusting the data structures/algorithm…
Once I got very confused when exactly this kind of 10k x speed up I demonstrated for a problem introduced to me as a business bottleneck then got ignored (I wasn’t on this team, though, but it’s still hard to understand the mentality and incentives there).
This sounds like being completely performance oblivious, like an extreme opposite of premature optimisation.
My rule of thumb is that as long as it doesn’t really complicate or convolute the code, write with performance in mind.
My expertise is in C# and sometimes this is as simple as using a hash set or dictionary instead of a plain list.
Other times it’s having a decent understanding of how EF (an ORM) actually works (the static typing benefits of them in C# makes ORMs very valuable when used appropriately) and the cost of round trips to any network host (including a DB).
a hashset was used... then ".Where(x=>x == key).Count() == 0"
Nitpick but 25% improvement over 8 quarters is 1.25^8, almost a runtime in 1/6th of the time.
25% faster is 1.33x work done in the same time. What you want is 0.75^7 (almost 2 years) gives you 13.3% of the original time, which is 1/7.5. Only it was more like 25-30% so I rounded up.
Interesting how people interpret the word faster differently.
To you, 2x faster means 2x the work done in the same time, but 25% faster means 1.33x the work done in the same time.
I see this a lot - in software people interpret 50% faster as a 50% reduction in time taken.
If a car is 50% faster, I hope people would universally interpret that as e.g. 20 to 30 mph. But if I asked people how long would a 1 hour journey take if it were 50% faster, I bet a lot would say 30 mins, because it kind of seems like that's what I mean.