C# String Comparison Tests
-
I was just reading someone's blog where he tested
bool isEmpty = (MyString == "");
// also
bool isEmpty = string.IsNullOrEmpty(MyString);
// also
bool isEmpty = string.IsNullOrWhiteSpace(MyString);
// also
bool isEmpty = MyString.Equals("");
// also
bool isEmpty = MyString.Length == 0;
and he listed the number of ticks each example took. That got me thinking.... If you wanted to know of a string was null, that's one thing, and determining if its an empty string is another. But do you REALLY care about TICKS??? With today's PC's and Servers running at ultra high speed, why would anyone really care? Bonus question: I prefer IsNullOrWhiteSpace. What's your favorite & why?
If it's not broken, fix it until it is
All are different functions but doing almost same work.So my choice better to use IsNullOrEmpty() as its safe and performance is good as compare to IsNullOrWhiteSpace().As IsNullOrWhiteSpace()can be removed if you are not using Unicode data.Apart from that other functions Equals and Length check functions having some performance issues in large projects. So I prefer ISNullOrEmpty() in many situation. At last its depend upopn the code what it needs. Thanks.
-
string MyString = null;
bool isEmpty = (MyString == "");What do you think the result of this little test is? (Slightly non-intuitive if you expect this to blow up because MyString is null).
string MyString = " ";
bool isEmpty = string.IsNullOrEmpty(MyString);Okay, is this an empty string? This is a common test to see if a user has entered some details - a space generally isn't considered true for entering details. We can dispense with the last two examples by using the same MyString = null assignment. Because it's null, neither will work so you'd have to issue a null check beforehand anyway. By omission, you can guess which my favourite is.
I'm in the same camp.. I like IsNullOrEmpty because it's really all you need.
If it's not broken, fix it until it is
-
I'm in the same camp.. I like IsNullOrEmpty because it's really all you need.
If it's not broken, fix it until it is
Ahem - my camp is strictly in the IsNullOrWhitespace field. I've pitched my tent, put on the gas stove and am boiling up a brew.
-
Ahem - my camp is strictly in the IsNullOrWhitespace field. I've pitched my tent, put on the gas stove and am boiling up a brew.
Pete O'Hanlon wrote:
I've pitched my tent, put on the gas stove and am boiling up a brew
Ahem, what about the biscuits?
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
Pete O'Hanlon wrote:
I've pitched my tent, put on the gas stove and am boiling up a brew
Ahem, what about the biscuits?
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
I expect my visitors will bring the Rich Tea.
I've got some Chocolate Hobnobs if you've got any coffee?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
I've got some Chocolate Hobnobs if you've got any coffee?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
You're on. You can't beat your chocolate hobnob. Well, not in a crowded campsite field anyway.
-
You're on. You can't beat your chocolate hobnob. Well, not in a crowded campsite field anyway.
Gentlemen I present, custard creams.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
Most of them are not even equivalent.. of course you can weigh both apples and oranges, but there aren't many useful conclusions that can be drawn from the results.
Coder For Hire wrote:
With today's PC's and Servers running at ultra high speed, why would anyone really care?
Moving into hypothetical territory here, it's easy to make up a scenario in which it matters. "Do that thing a billion times" is usually a good start. By the way, if you're referring to this blog[^], then disregard the results, that's a very bad benchmark, he makes all the rookie mistakes.
harold aptroot wrote:
By the way, if you're referring to this blog[^], then disregard the results, that's a very bad benchmark, he makes all the rookie mistakes.
I can identify these mistakes: - he uses DateTime.Now instead of StopWatch - he doesn't allow for JIT-precompilation - no GC.Collect() (which shouldn't matter much here but would be good practice) Are there more mistakes?
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
-
I was just reading someone's blog where he tested
bool isEmpty = (MyString == "");
// also
bool isEmpty = string.IsNullOrEmpty(MyString);
// also
bool isEmpty = string.IsNullOrWhiteSpace(MyString);
// also
bool isEmpty = MyString.Equals("");
// also
bool isEmpty = MyString.Length == 0;
and he listed the number of ticks each example took. That got me thinking.... If you wanted to know of a string was null, that's one thing, and determining if its an empty string is another. But do you REALLY care about TICKS??? With today's PC's and Servers running at ultra high speed, why would anyone really care? Bonus question: I prefer IsNullOrWhiteSpace. What's your favorite & why?
If it's not broken, fix it until it is
Just picking up on one specific part of your question :
Coder For Hire wrote:
But do you REALLY care about TICKS??? With today's PC's and Servers running at ultra high speed, why would anyone really care?
Ah, if only... For some usage, maybe not, but there are many application areas where performance is very important. Modern servers may be high performance, but if you're getting Google or Amazon rate hits, then your users might start to notice a slow-down. Gamers are also very critical of poor performance, and will notice if your refresh rate is too slow or, worse, not consistent. Been there, done that, and sometimes you work hard to squeeze out the last ounce of performance from a system. And there are a lot of systems out there running on lower-spec hardware, especially in the embedded world, and every cycle counts in those apps. Currently there and doing that - and again, you can't afford to waste any resources, processor, memory or I/O. Of course, I would very much hope that in any time-critical or mission-critical application, string comparisons were kept to an absolute minimum, but I have occasionally seen some coding horrors and "stringly typed" (to borrow a friend's phrase) parameters...
Days spent at sea are not deducted from one's alloted span - Phoenician proverb
-
harold aptroot wrote:
By the way, if you're referring to this blog[^], then disregard the results, that's a very bad benchmark, he makes all the rookie mistakes.
I can identify these mistakes: - he uses DateTime.Now instead of StopWatch - he doesn't allow for JIT-precompilation - no GC.Collect() (which shouldn't matter much here but would be good practice) Are there more mistakes?
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
A couple more, - the result goes nowhere. Apparently it worked, but it's dangerous (operation could be discarded, and really they should have been, so I have a sneaking suspicion it might have been run while suppressing JIT-optimization). - the whole thing is only done once. The worst part of that is the JIT-compilation, but there is also "turbo lag" (part of the first loop could run at a lower frequency), other start-up nonsense (extra cache misses and so on), and a semi-random number of context switches. - from these benchmarks, it's impossible to tell how much of the time taken is due to the loop overhead. - it's measuring a throughput but kind of implying it's a latency.
-
All are different functions but doing almost same work.So my choice better to use IsNullOrEmpty() as its safe and performance is good as compare to IsNullOrWhiteSpace().As IsNullOrWhiteSpace()can be removed if you are not using Unicode data.Apart from that other functions Equals and Length check functions having some performance issues in large projects. So I prefer ISNullOrEmpty() in many situation. At last its depend upopn the code what it needs. Thanks.
You do know that IsNullOrEmpty IS NOT the same as IsNullOrWhitespace don't you? If I were to paste a tab into a field, for instance, and I'm expecting it to contain a proper value, IsNullOrEmpty will let that past whereas IsNullOrWhitespace will properly identify that there's a whitespace character in there.
-
A couple more, - the result goes nowhere. Apparently it worked, but it's dangerous (operation could be discarded, and really they should have been, so I have a sneaking suspicion it might have been run while suppressing JIT-optimization). - the whole thing is only done once. The worst part of that is the JIT-compilation, but there is also "turbo lag" (part of the first loop could run at a lower frequency), other start-up nonsense (extra cache misses and so on), and a semi-random number of context switches. - from these benchmarks, it's impossible to tell how much of the time taken is due to the loop overhead. - it's measuring a throughput but kind of implying it's a latency.
Thank you, Harold! I got the first points but I don't see how he's implying that it's a latency - can you elaborate on that?
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
-
Thank you, Harold! I got the first points but I don't see how he's implying that it's a latency - can you elaborate on that?
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
Well, he doesn't really come right out and say it, but the way he puts things makes it look like it's about latency. Things like "worth the extra ticks" or "takes x ticks", none of it is actually wrong but I just get that vague sense that he doesn't really make the distinctions between how long something takes and how often you can do it in a unit of time.
-
Well, he doesn't really come right out and say it, but the way he puts things makes it look like it's about latency. Things like "worth the extra ticks" or "takes x ticks", none of it is actually wrong but I just get that vague sense that he doesn't really make the distinctions between how long something takes and how often you can do it in a unit of time.
Ah, alright. I thought I should be able to see that in the code :) Thank you, Harold.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
