On a side note: not caring about performance “until you find performance issues” is a huge problem with modern software imho. That’s the reason apps are so slow, updates take so long, everything uses so much space. I’d wish that performance would always be a point of consideration, not an afterthought once there are problems.
I’d rather people err on the side of readability… senior devs should know the importance of readability but still lay decent groundwork towards performance… do things the right way when it can be simple.
Junior developers should just focus on readable code. Chances are their code will be slow, indecipherable, and wrong - I’d rather they focused on fixing the indecipherablity, the wrongness, and then the speed.
But, to sort of generally undermine my own point - no rule should be an absolute in software development - sometimes premature optimization is totally justified - you just need to use common sense.
I agree that junior devs should focus on readability, rather than focusing on everything and just getting it all wrong. but as you say, if you have more experience, performance should be a point of consideration.
I think people talking about premature optimisation are often talking about micro-optimisations. Those are almost always unnecessary until you’ve identified choke points. Optimising the overall architecture of the code base on the other hand, is in my opinion something that should be thought about before you even start coding. That’s where the major gains can often be done anyway.
I don’t think loop vs recursion choice is what significantly impacts performance in most cases. Most of the software I saw, suffer performance because of wrong API design or overall architecture. If app needs to fetch 100 objects from API which can provide only one object at the time no optimization will save that app.
App team - we need bulk API.
API team - cannot because of capacity, budget, backward compatibility, DB, 3rd patry API, not a KPI
Also it’s mostly QAs measuring performance and validating it with product guidelines which set by person who mostly detached from specific product and sometimes reality.
I think loops tend to be faster, but well done recursion might be just as fast. I just wanted to mention performance being a point of consideration when making these decisions.
I 100% agree that poor (API) architecture is probably one of the biggest reasons for slow software.
It’s just that every bit of poor performance adds up along the way, and then we end up having fast computers (that are orders of magnitude faster than anything 15 years ago) running bloated electron apps (that are sometimes even slower than their equivalent 15 years ago) and it’s just frustrating.
Just adding on that recursion could be problematic if used in the wrong way, like too many calls can over flow the call stack (assuming the compiler is not able to optimize that away).
Yeah but performance has way more to do with architecture than it does code readability. It doesn’t matter how well you write your code, if it’s an electron app it’s going to use more ram than a native app. So I totally agree, but at the scale that it’s a real problem it has more to do with architecture than the code in any given function.
Yeah but performance has way more to do with architecture than it does code readability.
Indeed, I am a bit notorious at work for speeding C++ code up by rewriting it in Python, and I have been able to do this not because my Python code is particularly fast but because the architecture of the C++ code was such a complicated and inefficient mess that it actually managed to be slower than Python.
On a side note: not caring about performance “until you find performance issues” is a huge problem with modern software imho. That’s the reason apps are so slow, updates take so long, everything uses so much space. I’d wish that performance would always be a point of consideration, not an afterthought once there are problems.
I’d rather people err on the side of readability… senior devs should know the importance of readability but still lay decent groundwork towards performance… do things the right way when it can be simple.
Junior developers should just focus on readable code. Chances are their code will be slow, indecipherable, and wrong - I’d rather they focused on fixing the indecipherablity, the wrongness, and then the speed.
But, to sort of generally undermine my own point - no rule should be an absolute in software development - sometimes premature optimization is totally justified - you just need to use common sense.
I agree that junior devs should focus on readability, rather than focusing on everything and just getting it all wrong. but as you say, if you have more experience, performance should be a point of consideration.
I think people talking about premature optimisation are often talking about micro-optimisations. Those are almost always unnecessary until you’ve identified choke points. Optimising the overall architecture of the code base on the other hand, is in my opinion something that should be thought about before you even start coding. That’s where the major gains can often be done anyway.
I don’t think loop vs recursion choice is what significantly impacts performance in most cases. Most of the software I saw, suffer performance because of wrong API design or overall architecture. If app needs to fetch 100 objects from API which can provide only one object at the time no optimization will save that app.
App team - we need bulk API.
API team - cannot because of capacity, budget, backward compatibility, DB, 3rd patry API, not a KPI
Also it’s mostly QAs measuring performance and validating it with product guidelines which set by person who mostly detached from specific product and sometimes reality.
I think loops tend to be faster, but well done recursion might be just as fast. I just wanted to mention performance being a point of consideration when making these decisions. I 100% agree that poor (API) architecture is probably one of the biggest reasons for slow software. It’s just that every bit of poor performance adds up along the way, and then we end up having fast computers (that are orders of magnitude faster than anything 15 years ago) running bloated electron apps (that are sometimes even slower than their equivalent 15 years ago) and it’s just frustrating.
Just adding on that recursion could be problematic if used in the wrong way, like too many calls can over flow the call stack (assuming the compiler is not able to optimize that away).
Yeah but performance has way more to do with architecture than it does code readability. It doesn’t matter how well you write your code, if it’s an electron app it’s going to use more ram than a native app. So I totally agree, but at the scale that it’s a real problem it has more to do with architecture than the code in any given function.
Indeed, I am a bit notorious at work for speeding C++ code up by rewriting it in Python, and I have been able to do this not because my Python code is particularly fast but because the architecture of the C++ code was such a complicated and inefficient mess that it actually managed to be slower than Python.
That just hurts me. I love to bag on Python for being slow. But that also totally makes sense.