

On Premature Optimization - cramforce
http://www.nonblocking.io/2011/02/on-premature-optimization.html

======
chipsy
I think the "root of all evil" comes from _discussions_ of premature
optimization in public forums, not the act itself. Optimization discussions
tend to take these archetypes:

* 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.

------
Xurinos
Every time this phrase comes up, we need the context again, which conveys a
different picture from the tiny and not-so-useful piece taken from it (and
which the author successfully adhered to -- kudos!):

"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

------
stcredzero
_String builder and concatenation - > use concatenation_

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.

------
sdizdar
I would like just to add that sometimes "premature optimization" is confused
with "performance decoration". Performance decoration is process in which you
make software to look fast but without any positive impact on actual delivered
performance.

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.

------
nvictor
Strangely enough, I started my quote website project with a quote on
optimization. Coming from the very best:

<http://the-quotes.appspot.com/topic/optimization>

