performance junkie == good programmer
I happen to believe that. Here is why. Going after performance implies that
you were a good programmer, otherwise you'd have no base to improve on
performance. You'd lack the theory. You'd lack the coding technique. You'd
lack the fundamental knowledge about optimization to tackle that kind of
thing. You wouldn't know where to start.
On the contrary - lots of people go after performance not realising
that:
a) By concentrating more on the design in the first place than the
details later on, they could probably have gained more performance
anyway.
b) By concentrating on simple, readable code instead of code which runs
very quickly, they're likely to have fewer bugs.
c) Going after performance where it's not needed is just a waste of
effort.
Being a performance junkie isn't the same as being concerned about
performance where necessary - the latter suggests that you understand
that not every piece of code *does* need to be optimised, because most
of your code won't end up as a bottleneck.
It's like saying fighter pilot == a good pilot. How can you sit in a test
cockpit harness if you can't fly well. You have to be a good programmer
first, then you graduate into a performance junkie.
That's not the way it happens though - people try to go after
performance when they really don't need to, and indeed shouldn't due to
the loss of readability which is often involved when going for really
fast code.
It really doesn't matter to me if I'm writing code for the defense
department or for the science school team. The habits ingrained in me force
me to find the most efficient way to write code.
In that case you won't be writing the most readable code. There's
almost always a trade-off between performance and readability, even if
it's only a fairly slight one.
So i will replace
stringbuilders with strings (don't quite believe the stringbuilder hype) and
i will not normally write foreach loops instead of for loops. It doesn't
necessarily make my code always run faster than yours, i do it because it's
a good habit to write performant code. I do it because i believe it pays
divends later, but mostly out of habit. Readability is pretty much a given
these days. This is not the days of C++ when a pointer could leave the
screen and walk on the desktop.
Readability is certainly *not* a given. Readability varies *enormously*
between programmers, and I believe that things like foreach improve
readability greatly - they very efficiently state that they're
iterating through the elements in a sequence of some description.
In my view, readability should be number one on the list of a
programmer's priorities - even before getting the code working
properly! It's easy to get from code which doesn't work but is readable
to code which does work but remains readable - far more so than getting
code which is messy but works to code which is readable and still
works. The same kind of thing is true for performance - get it working
simply and reliably first, then find out where it's not performing,
then fix that bit of the code if you really need to, after measuring
appropriately.
The order in which I'd develop in an ideal world would go something
like:
1) Write class specification, bearing in mind architectural
performance (often more of a system issue than an individual class
issue)
2) Write class documentation and empty method stubs
3) Write unit testing code
4) Write first pass simple implementation
5) Get that implementation working against all the tests
6) Run system tests (developed in parallel by a separate team,
probably) including performance measurements
7) If system doesn't perform adequately, isolate bottleneck and
optimise
