last LinqPad performance benchmark in this week - something to now about string.Empty and ""

 As we shall learn all life and never retire from learning - today my closed brain read rfm about using benchmarkDotNet in LPad, so  one can benchmark a code snippet by just selecting it and pressing CTRL+SHIT+B 

The tests were done for .Net 5.0, 6.0 and 7.0 framework versions. As you will see, the results are pretty interesting (and I repeated them a few times)  giving us a few conclusions:

  • I was told to use string.Empty instead of "" for performance, not a case in those results, especially for v7.0
  • I am not sure if the benchmark runner has good ability to test those small operations and I even repeated in one case creation of  a string variables, but the results vere proportional.
  • I need to use full BenchmarkDotNet next time to compare those results, but inside I am curious why the is so big change in the timing.
  • I will still use string.Empty as for me it is easier to decode the code when reading





Comments

Post a Comment

Popular posts from this blog

can you believe that more code gives ability to add much more faster?

Image
In last blog click  we have the chance to refactor a logic expression to be more developer friendly, but it was generating more IL code lines. I was wondering if that will have an impact on the performance (u know when u use a language that is focused on extending your product not on high performance - then this is a bit of over engineering case 💩💩💩). So yes, I made a benchmark in LinqPad making my friend Selciuk unhappy a bit, but the results are very interesting. In 2 form 5 test cases, refactored code was performing a bit better, but I am more happy that in the other three cases it was not terribly slow, with a maximum of 4% slower. So having those results, let's say that it is more important to write code that is easier to extend!  If you willing to write a high performance stuff - then you need to be ready to decipher every line, every time when you read it :D.
Read more

an actual controversy switch vs if chain (a benchmark example using LinqPad 7 free edition), but the real problem was hidden in a different place [refactoring stuff]

Image
 In Linqpad 7 user can execute BenchmarkDotNet, as I love LinqPad for it is simplicity and ability to test somestuff without the burden of creating a project. After installation (of LinqPad) we can find a predefined query called BenchmarkDotNet, with an example benchmarks defined, so we can start 'doing stuff' After first run we can see that all methods with attribute [Benchmark] are executed in the harness, so we can start digging.  Right click on the query and select use as a template - so we will not use the orginal one.  The simple code is here:  gist  (and at the end of this post) Creating a class for each method allows to have it nicely displayed on the results pane. From the benchmark results we can see  that there is nothing to worry with the practicular code as both methods have fairly same time of execution - and let's try to add more steps (up to 10 and see if we will be still close or switch will take an advantage) And the results are very inter...
Read more

an overdose of strings can kill you - really?

Image
 In recent years I remember a discussion about a 3 lines of code, it was something easy, so let's have a look at this: As we can see, an one liner statement was replaced with a string builder.  As this is a reset password, then we shall not focus on performance as our users rest password once in a year, but the discussion was based on a style how that was done, so let me bring what we discussed. Frist, a string builder is a great tool for dynamic text and in this case we have only one variable - so it is overkill. Secondly templating shall be moved away from logic as this is pure implementation of the process. So I ran a benchmark, just to confirm that SB is an overkill: Now I will add a static string that will be our template, and we can see if string.Replace can help us (imho string.Replace is a heavy and will use more memory, thus it can be heavy on CPU too). As we can see, the refactor gave us a nice looking code, one line for the template, but we lost a bit on the perform...
Read more