Hilton said:
I couldn't disgree more, but that's just me. My goal is to build in
performance and quality, not test it in. Then again, I write primarily for
the Pocket PC and Smartphone, so I really have to think about performance.
Everyone has to think about performance, regardless of platform.
Everyone should write code that performs well.
But for most code, all this really means is to not write inefficient
_algorithms_. Don't use an algorithm that is O(N^2), or even O(N log N)
for that matter, when an O(N) algorithm will do.
Differences in implementation of the same algorithm are not likely to
produce a performance difference that the user will notice in most
cases, while other aspects of the implementation such as overall code
maintainability and obviousness of the implementation details often do,
in the form of code that actually _works_ and doesn't have unanticipated
complications.
In addition, while one can test performance of a specific section of
code, there is not even any guarantee that such tests will translate
into a real-world application. There is more to the question of
performance than just what the basic CPU instruction timing can tell
you. For example, code that performs better in a specific scenario, but
which is larger than a similar, simpler version of the same algorithm
may in fact under-perform in other scenarios, whether due to interaction
with surrounding code or differences in the exact hardware
configuration, etc.
And of course, if you manage to squeeze a 50% improvement (an unusually
large optimization result, assuming a correct algorithm has been
designed in the first place) out of code that only consumes 1% or less
of the total execution cost, you haven't achieved anything the user will
ever care about.
So, even if you manage to prove one implementation performs better than
another in a specific situation, that isn't necessarily going to
translate into better performance for the end user.
Every software project has a finite amount of man-hours that can be
applied to it. You are doing your users a disservice if you spend some
of those man-hours optimizing code that has no need of optimization,
rather than doing things like adding features or ensuring that the code
is easily maintained, especially since those hours spent optimizing may
in fact have counter-productive results.
IMHO, the question of whether to use a new instance versus clearing an
existing one should relate more to what makes the code more readable
than which performs better. And in many cases, having an instance local
to a loop and which is initialized in each iteration of the loop is much
more readable and easily-maintained. (And in other cases, it may not be
in which case one would choose an alternate method).
As Patrick and Jon have both said, once you have a complete
implementation, then it makes sense to identify and address any
potential performance problems. At that point, you will know what areas
of the code are actually affecting the user experience, and you will be
able to measure changes in the implementation in a way that takes into
account the context of those changes.
Pete
)