Alpha83 said:
Is there a code measuring tool that tells you which is more efficient
cost-wise. For example, if I were to compare the following two
identical code blocks, how do I know, which is more expensive CPU
wise :
//compare 2 strings
1. if (str1 == str2) ....
2. if (String.Compare(str1, str2, true) == 0) ....
Forget the efficiency, worry about correctness first. The code snippets
you've given are not equivalent, much less identical. The first does a
culture-insensitive ordinal comparison of the two strings (in other words,
they have to be byte-for-byte equal) while the second does a
culture-sensitive, case-insensitive comparison (in other words, they could
literally have no byte in common but still contain the same characters as
far as the comparison is concerned).
Even without a profiler (that's the kind of tool you're looking for) I can
tell you that the first snippet is faster (because, barring a very poor
implementation, a byte-for-byte comparison will always be faster than one
that takes culture and case into account), but that's pretty much
meaningless because the statements aren't comparable.
What you want to do is get the program correct first, and efficiency should
only come in as a broad design criterion here in the sense of not doing
anything obviously silly (like searching many times in a big unsorted array
as opposed to sorting it first) but not in worrying about what exact lines
of code are most efficient.
If after that you find that your program is doing its job fast enough, leave
it alone. Go do something else. Only if your program is not doing its job
fast enough should you get out a profiler (there are many such tools for
..NET available, some free) and find out where its spending the most of its
time. Focus on optimizing that part to the point where your program is
either fast enough (in which case you're done) or until the part you're
optimizing no longer dominates the runtime of your application (in which
case, profile again and repeat until done).
Micro-benchmarks (where you do some simple timing of a piece of code
executed many times, for example with the help of the Stopwatch class)
usually harm more than they help. They are somewhat useful for quickly
determining whether a particular piece of code is obviously faster or slower
than its alternative, but even then they're misleading, since they can't
take into account the actual workload.
In any case, you'll want to make sure that whatever you're optimizing still
does the same thing when you're done with it. Unit testing is indispensable
here, as is understanding the methods you're calling. If you actually
"optimized" string comparison in the manner above, you might be in for a
rude surprise.
