On Premature Optimization
nonblocking.io
nonblocking.io
* Existing performance problem
* Concerns about planning architecture/approaches
* I want to make it fast, is this plan a good one?
The first two can be OK, although in most cases the second goes nowhere because nobody has the deep and highly specific domain knowledge needed to help with estimating performance in the large.
The last kind is the worst - the person who initiates the discussion has already decided that there is a problem and tried to act on it, and oftentimes wants to brag a bit, and now people can either tell him he's right(boring) or he's wrong/premature(causing conflict). Since these days, most of the time it's premature, there's a huge cargo cult of programmers who essentially say "never optimize." This cult battles against both the performance freaks, and the people who are simply curious about learning and applying more optimization techniques.
Internally to a team, the discussion is fundamentally different as it's made within the context of ship date, spec, etc. Any debate is ultimately settled by the leadership, right or wrong. It only becomes a problem when people can hold the debate in a realm of unbounded perfectionism.
Besides, if you keep your mouth shut, you usually discover for yourself if it was a good idea to bother optimizing.
"There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance a considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3 %. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified." --Knuth, emphasis mine
My recommendation: pick some appropriate value of n, and make it a coding standard to use it for chains of concatenation larger than that. You can even profile this in your app, in your actual environment to pick a value of n empirically determined to be around the actual performance crossover point.
Is this pre-optimization? Debatable, if you make your decision based on profiling. The thing is, that in this case, there are a lot of places where this sort of thing can appear. A coding standard like this isn't costly, and by taking this step, you reduce a lot of memory allocation and O(n^2) inefficiency noise when you do your profiling.
Even better: JIT VMs that can optimize out chains of concatenation behind the scenes.
Also, there are two ways to make software go faster: do what you’re doing quicker or make it do less stuff. It is nearly always better to go "do less stuff" path.