|
I know the problem.
It ain't like riding a bike -- if you don't do something for a long time, you forget how to do it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
(I was torn between putting these here or in the C# forum, but it not really a serious question...)
Given a simple string
const string _str = "abcdefghijklmnopqrstuvwxyz";
put the following equivalent code blocks in order of their speed:
if ( _str.Contains("~")) {....}
if ( _str.Contains('~')) {....}
if ( _str.IndexOf("~") >= 0) {....}
if ( _str.IndexOf('~') >= 0) {....}
if ( _str.IndexOf("~", StringComparison.Ordinal) >= 0) {....}
Hint: there are three tiers --- One is the clear winning. Two others are about the same, significantly behind, and the last two are about the same, way behind the others.
Truth,
James
|
|
|
|
|
I did cheat, and run a quick console app.
But D seems fastest, very closely followed by B. Barely really.
Then A, and behind A is E.
Slowest is C.
|
|
|
|
|
Hmmmm Very interesting results.
I ran my test using BenchmarkDotNet, with a longer string, with a "~" near the end.
Now, the whole point of this was that I found some code using A, and I figured that B should be faster.
So, I ran the test-- and in mine, B came out way last.
Studying it source code, I found that A just redirects to E, so they were nearly the same.
B, however, uses String's IEnumerable<char> interface to run the Enumerable.Contains<char>() extension method, which is why it was last.
C I tried, mistakenly thinking it would be the same as E. It came out nearly tied with B for last.
D was my overall winner as well.
So, it seems you are experiencing a String.Contains(char) which is specific for strings, which I am not seeing.
I ran the tests on .NET 4.6.1. Are you using .NET Core?
Truth,
James
|
|
|
|
|
Yep, I used .NET Core which may explain the difference.
|
|
|
|
|
Upvoted for 'cheating' being scientific - there's nothing wrong with empirical proof, its exactely what I thought when I saw the question, ie, 'why guess' ..
|
|
|
|
|
Thanks, good way of looking at it I suppose.
|
|
|
|
|
This is the code I ran in release mode. (.NET Core)
class Program
{
const string _str = "abcdefghijklmnopqrstuvwxyz";
static void Main(string[] args)
{
Foo("A", () => _str.Contains("~"));
Foo ("B", () => _str.Contains('~'));
Foo("C", () => _str.IndexOf("~") >= 0);
Foo("D", () => _str.IndexOf('~') >= 0);
Foo("E", () => _str.IndexOf("~", StringComparison.Ordinal) >= 0);
}
static void Foo(string s, Func<bool> action)
{
var sw = new Stopwatch();
sw.Start();
for (int i = 0; i < 1000000; i++)
{
action();
}
sw.Stop();
Console.WriteLine($"{s} - {sw.Elapsed.Milliseconds}");
}
}
|
|
|
|
|
In my experience, the speed measurements at the start of an app are always polluted by the runtime initialization. That is, it might look that "A" takes longer than "B", where actually does not.
Typically, I copy the same piece of code two or three times, then I take the last results.
Have a try, maybe the results will change, maybe not.
|
|
|
|
|
Mario Vernari wrote: Typically, I copy the same piece of code two or three times, then I take the last results. I use sleep 5 seconds, then go for it.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
I'm just an old C++ dinosaur, so my guess is that B and D are the fastest, followed by A and C, and finally the indecipherable twaddle of E--unless it's some kind of secret code for "Hint: you're looking for a single character and therefore don't have to construct "~" , in which case it's probably faster than A and C but slower than B and D.
|
|
|
|
|
Greg Utas wrote: finally the indecipherable twaddle of E--unless it's some kind of secret code for "Hint: you're looking for a single character and therefore don't have to construct "~"
Nope: it's saying "Look for this using a binary comparison, rather than using a culture or shift specific sort order" - basically "compare strings as byte arrays" but using 16 bit values. In theory, this should be much quicker than a non-ordinal comparison as you don't have to deal with "special cases" or "'t' == 'T'", and most processors have machine code instructions for byte based searching and comparing.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Next time I can't decipher some twaddle, I'll know who to turn to.
|
|
|
|
|
|
No, it's ok. Read the sticky on top: The Lounge[^] Point2: Technical discussions are welcome...
|
|
|
|
|
Jorgen is right - this isn't a question seeking help, it's a "Hey! look at this!" discussion.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Also one of the more interesting posts here in recent times.
|
|
|
|
|
Something similar I tried some years ago: Counting Lines in a String[^]
It shows another couple of methods you could have tried.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
After close examination, the fastest option is 'skip that block'.
|
|
|
|
|
It might well depend on the string being searched and what is being searched.
|
|
|
|
|
|
Sigh... I was in passionate relationship with VMS from 1980 to 1994. The end of era...[^]
/ravi
|
|
|
|
|
I feel your pain, Ravi. My experience with VAX/VMS ended before yours in 1989, but I still remember the amazing feeling of consistency about things, and how Everything Just Worked.
Software Zen: delete this;
|
|
|
|
|
I first did serious programming on a PDP-10 and felt the same way about it.
|
|
|
|