Peter Duniho said:
I don't think your guess was a bad one, but I think Arne's point is
sound. If you care about performance, the only correct approach is to
measure and analyze. Choosing implementation details based on assumptions
of performance characteristics doesn't make sense.
I agree with what you say, however I think all good programmers make many
such educated guesses every day. I don't have time to performance check
every line of code I write but I can get pretty good performance by going on
lots of good guesses. As it turns out my "guess" in this case appears to be
accurate. I didn't think I was going out on much of a limb and it turns out
that everything I said was accurate, string.Compare is faster, it is more
efficient, it doesn't create a copy and ToLower does.
Of course, in most cases, the performance details are unimportant. But in
that case, the implementation details should be chosen based on what makes
the simplest, most maintainable code. Any mention of performance is just
a red herring.
That is true but when faced with 2 similar pieces of code I will often go
with the one that I think will have the best performance. I think the
ToLower comparison is possibly slightly more readable but the string.Compare
is the better method. It definately possible to go overboard on the
readability, a balance is always good.
String doesn't keep track of whether it was created using ToLower(). So,
even if the string has already been lower-cased, it has no way to avoid
creating a copy.
You are correct, I was thinking it might not create the copy until it
encounters a change but I just ran a test and it creates a copy in all
cases. I'm not sure how Arne ran his test but I found a significant
difference between the 2 methods on a 200meg string.
However, there's an important omission in Arne's performance description:
he didn't actually post the code, so we have no idea what his test
actually did.
Yep, I would be interested to see it and how he managed to get ToLower to be
faster.
Michael