|
Some tests to check some functions not tested in link below:
Performance Improvements in .NET 6 - .NET Blog (arrays-strings-spans)
.NET 6.0 is (comparing its performance to .NET Framework 4.8):
• 3x faster on String.Replace operations
• 16x slower on String.IndexOf operations,
• 1.4x faster on String.Substring operations
• The same on String.Remove operations
Copy paste the code below and compile with .NET 6.0 and .NET Framework 4.8 and see by yourself.
string test = "Lorem Ipsum is simply dummy text" +
" of the printing and typesetting industry. " +
"Lorem Ipsum has been the industry's " +
"standard dummy text ever since the 1500s, " +
"when an unknown printer took a galley " +
"of type and scrambled it to make a type specimen book. " +
"It has survived not only " +
"five centuries, but also the leap into electronic typesetting," +
" remaining essentially unchanged." +
" It was popularised in the 1960s with the release" +
" of Letraset sheets containing Lorem Ipsum passages," +
" and more recently with desktop publishing software like " +
"Aldus PageMaker including versions of Lorem Ipsum.";
System.Diagnostics.Stopwatch K = new System.Diagnostics.Stopwatch();
K.Reset(); K.Start();
for (var v = 1; v <= 10000000; v++)
{
test = test.Replace("a", "bla bla bla bla");
test = test.Replace("bla bla bla bla", "a");
}
K.Stop();
System.Console.WriteLine($"Elapsed Time for [String.Replace]: {K.Elapsed.TotalSeconds} sec");
K.Reset(); K.Start();
for (var v = 1; v <= 1000000; v++)
{
int i = test.IndexOf("including versions of Lorem Ipsum");
}
K.Stop();
System.Console.WriteLine($"Elapsed Time for [String.IndexOf]: {K.Elapsed.TotalSeconds} sec");
K.Reset(); K.Start();
for (var v = 1; v <= 600000000; v++)
{
var s = test.Substring(25, 50);
}
K.Stop();
System.Console.WriteLine($"Elapsed Time for [String.SubString]: {K.Elapsed.TotalSeconds} sec");
K.Reset(); K.Start();
for (var v = 1; v <= 90000000; v++)
{
var s = test.Remove(45, 60);
}
K.Stop();
System.Console.WriteLine($"Elapsed Time for [String.Remove]: {K.Elapsed.TotalSeconds} sec");
System.Console.WriteLine("Press a key to exit...");
System.Console.ReadKey();
|
|
|
|
|
I don't have .net 6 available.
Might be better not to use a StopWatch for those tests.
Is it a debug build?
How long are those tests taking? Do they take "long enough" for a proper test?
|
|
|
|
|
for (var v = 1; v <= 1000000; v++)
|
|
|
|
|
Yes, so how long does it take?
|
|
|
|
|
PIEBALDconsult wrote: Yes, so how long does it take?
Computer: Intel Core I5
.NET 6.0:
Elapsed Time for [String.Replace]: 17.1540338 sec
Elapsed Time for [String.IndexOf]: 32.473905 sec
Elapsed Time for [String.SubString]: 11.9497695 sec
Elapsed Time for [String.Remove]: 9.2207969 sec
.NET 4.8
Elapsed Time for [String.Replace]: 47.532167 sec
Elapsed Time for [String.IndexOf]: 2.3447133 sec
Elapsed Time for [String.SubString]: 12.1748157 sec
Elapsed Time for [String.Remove]: 11.4768551 sec
modified 4-Jun-22 11:46am.
|
|
|
|
|
Hi,
Can you run the String.IndexOf benchmark again using StringComparison.Ordinal and post the result?
|
|
|
|
|
Randor wrote: Can you run the String.IndexOf benchmark again using StringComparison.Ordinal and post the result?
Thanks, it is the solution:
Now .NET 6.0 is 2X times FASTER than .NET Framework 4.8
Starting tests for .NET Framework 3.5, wait...
Elapsed Time for [String.Replace]: 51,0830947 sec
Elapsed Time for [String.IndexOf]: 0,5451713 sec
Elapsed Time for [String.Contains]: 0,5424978 sec
Elapsed Time for [String.SubString]: 17,7345287 sec
Elapsed Time for [String.Remove]: 15,021131 sec
Elapsed Time for [.NET 3.5]: 84,9272387 sec
Starting tests for .NET Framework 4.8, wait...
Elapsed Time for [String.Replace]: 53,2363039 sec
Elapsed Time for [String.IndexOf]: 0,5760411 sec
Elapsed Time for [String.Contains]: 0,595356 sec
Elapsed Time for [String.SubString]: 14,8117435 sec
Elapsed Time for [String.Remove]: 11,2053769 sec
Elapsed Time for [.NET 4.8]: 80,4258634 sec
Starting tests for .NET 6.0, wait...
Elapsed Time for [String.Replace]: 18,5094685 sec
Elapsed Time for [String.IndexOf]: 0,3495122 sec
Elapsed Time for [String.Contains]: 0,32621 sec
Elapsed Time for [String.SubString]: 12,1062252 sec
Elapsed Time for [String.Remove]: 10,1427749 sec
Elapsed Time for [.NET 6.0]: 41,4367067 sec
|
|
|
|
|
Yep,
Nobody even noticed my post. 
Thanks for running the benchmark, I suspected it would be faster.
|
|
|
|
|
It's advisable to use a real benchmarking framework when you want to benchmark operations.
|
|
|
|
|
Pete O'Hanlon wrote: It's advisable to use a real benchmarking framework
Not in this case, StopWatch is sufficient.
|
|
|
|
|
georani wrote: Not in this case, StopWatch is sufficient.
Benchmark.NET makes sure that code is warmed up properly, eliminating simple things like tiered compilation whose defaults may have changed between .NET versions, for example. It also makes it fairly trivial to compare different runtimes: it is, after all, the tool that Microsoft itself uses for comparison of runtimes (to consciously decide when performance regressions are acceptable).
|
|
|
|
|
Does it really matter in real world applications ? it never has in one's I've been involved in
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
pkfox wrote: Does it really matter in real world applications ?
Yes, my application become unusable after porting it to .NET 6, it uses a lot of string.IndexOf functions.
|
|
|
|
|
|
They probably fixed it make it theoretically faster to find a random string inside another random string which makes it worse for most common usage.
Is it possible that they are creating more objects with the new library to enable simpler garbage collection across multiple/asynchronous threads? There might be different design goals at play.
There was an interesting article I read years ago about some of the algorithms used for string functions in the early BASIC releases.
|
|
|
|
|
You didn't / should be using / comparing StringBuilder.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
|
That doesn't mean you exclude it.
For that matter, if the string is already loaded in a StringBuilder, then use (SB instance).ToString().IndexOf()
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
|
Eddy Vluggen wrote: Note the #1 in all tests.
Thank you. I will test it it.
And C Language seems to be a great choice. Or Golang. Or Rust.
|
|
|
|
|
C because it close to assembly. Golang or rust aren't competing there.
If it is a core function of what you do, then it'd make sense; eliminate the dependency.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Machine code generated from Rust usually levels with C in terms of raw performance, often outperforming it
|
|
|
|
|
Sure.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I'd be interested to learn why "rust isn't competing here".
|
|
|
|
|
It's a LLVM.
Running in a fictional machine.
On top of a real machine. 
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
