3 ms·

Ask any performance expert and they will tell you not to prematurely optimize your program. All of them. Yes, every single one of them. 100% of people with deep

Ask any performance expert and they will tell you not to prematurely optimize your program. All of them. Yes, every single one of them. 100% of people with deep performance experience will tell you not to prematurely optimize your code. I have spent much of my career working on performance-sensitive and/or resource-constrained systems of one kind of another, and the above is simply not true. Performance is like security or reliability. Yes, sometimes you find local weak spots, and sometimes you can do something locally to improve them. Profilers are great and changes should be based on measurements of real performance; no argument from me there. But in general, these are global concerns. You can't always retrofit "acceptable performance" using a profiler and local changes down the line, any more than you can retrofit "robust security". If it matters for your application, it needs to be considered from day one, and your overall design at least needs to allow for doing the right things even if you choose to not then implement those things in full immediately. Needlessly busting your cache is a common source of performance problems on many modern platforms, and that is essentially what you're doing by passing inline functions as props when rendering React components whose render algorithm is expensive enough to use shouldComponentUpdate. Ironically, from the discussion later in the article, the author does seem to understand to some extent, so it's frustrating that they still lead with such a patronising introduction, and that they keep generalising their own experience when not everyone will be working on the kinds of projects where the same assumptions are valid. There are some useful ideas in this article, which I'm sure would be relevant to a lot of React-using developers, but they get a bit lost among the strange and/or dubious assumptions that underpin much of the author's arguments.

baddox 9y ago
Doesn’t “doing premature optimization” just mean “doing optimization before you ought to be,” and thus the phrase is a tautology if provided without any context or explanation? Obviously any useful advice isn’t just “don’t prematurely optimize,” but rather explains how to recognize premature optimization. I like the advice in this article to write things naturally until you have data that demonstrates that a refactor will improve performance. Obviously experienced engineers will make deliberate optimizations up front without measuring. A great example is making sure your ORM uses a join instead of making N+1 queries: http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations http://guides.rubyonrails.org/active_record_querying.html#ea.... Yes, a small app could probably get away with N+1 queries for a long time, but I wouldn’t consider writing this properly to be a premature optimization.
- Silhouette 9y ago
  I suppose my point is that for applications where performance is a significant issue at all, there may be no useful interpretation of "premature optimisation". You have to design with at least the ability to code efficiently from the start, without relying on abstractions that hide performance traps. Otherwise you can back yourself into a corner where the only way out is to redesign or even entirely rewrite large parts of your code, and I think it would be generous to consider that sort of change a mere optimisation.

baddox 9y ago

Doesn’t “doing premature optimization” just mean “doing optimization before you ought to be,” and thus the phrase is a tautology if provided without any context or explanation? Obviously any useful advice isn’t just “don’t prematurely optimize,” but rather explains how to recognize premature optimization. I like the advice in this article to write things naturally until you have data that demonstrates that a refactor will improve performance. Obviously experienced engineers will make deliberate optimizations up front without measuring. A great example is making sure your ORM uses a join instead of making N+1 queries: http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations http://guides.rubyonrails.org/active_record_querying.html#ea.... Yes, a small app could probably get away with N+1 queries for a long time, but I wouldn’t consider writing this properly to be a premature optimization.

Silhouette 9y ago
I suppose my point is that for applications where performance is a significant issue at all, there may be no useful interpretation of "premature optimisation". You have to design with at least the ability to code efficiently from the start, without relying on abstractions that hide performance traps. Otherwise you can back yourself into a corner where the only way out is to redesign or even entirely rewrite large parts of your code, and I think it would be generous to consider that sort of change a mere optimisation.