3 ms·
> It is a similar pitfall that developers step into when they optimize their code before profiling where the bottlenecks are at. I heard this many times and be
by erikpukinskis 8y ago
> It is a similar pitfall that developers step into when they optimize their code before profiling where the bottlenecks are at.
I heard this many times and believed it, but after some time I think this is bad advice.
Here's mine:
There are two kinds of performance optimizations: free optimizations and optimizations with a cost.
The free ones are things that don't really take any extra complexity to implement, just a little thought. Using a hashed data structure instead of an array when you'll be accessing items randomly by id. Breaking early from a loop.
If you never think about these things unless you're explicitly on a profiling task, your code base will be full of "easy wins" that you have to go back and find and fix. Which will be time consuming and error prone if you do it after all your code is written.
The other group of performance fixes is ones with a complexity cost: adding a cache layer, rewriting an algorithm in a slightly more confusing way, etc.
My advice is: always pause when you are designing a new feature and think about whether there are "free" performance wins. You can implement them now with no cost, and you should. It often helps with your data design anyway, getting code that more closely matches the actual processing domain.
It doesn't have to take more than a minute. Anything bigger than that, yes: punt it til after you have profiled.
- ses1984 8y agoYou're not wrong, but I don't think anyone is saying you shouldn't use appropriate data structures. To me the advice means don't belabor the choice of data structure of its not obvious to you. If you're writing a quad nested for loop to solve a problem, don't get distracted trying to refractor all the work leading up to that wart... Just get it down first. Get a passing test first then optimize later if the code is a bottleneck.
- TeMPOraL 8y ago> Get a passing test first then optimize later if the code is a bottleneck. In that case, totally get that test passing and then maybe add few more tests around that solution - so that when I come to the project half a year later, and see the application consing like crazy because you used lists instead of arrays, and this now powers half of the business logic, I can tear this up and fix the data structure with confidence I won't break things badly. (Totally not a real case I had.)
- jmull 8y agoI guess it's just semantics, but if you can think of two ways you could do something and both are about the same in terms of time-to-implement, readability, complexity, etc., but one is probably faster... then I wouldn't call it an optimization. That's just writing good code in the first place.
- TeMPOraL 8y agoIt is, but people still use the "premature optimization" adage as an excuse to avoid thinking about performance at all. As GP is saying, at any given complexity and readability level, you can write the code in a more and less performant way. Writing more efficient code takes just a) willingness to consider performance, and b) willingness to actually learn your toolset as you use it.
- srean 8y agoYou wouldn't but the sad fact is that there are many cargo culters and trigger happy advisors who would think exactly that.
- taude 8y agoI like optimizations that also free up cognitive load. So that even if you can't "justify" the time savings from spending a couple days optimizing something, it might pay bigger dividends in not having to think about item again.
- james_s_tayler 8y agoThese are my favorite kind.