0

I have this code in my console app, which I'm running to measure the perf impact of using switch-case to map strings to chars:

static void Main(string[] args)
{
    for (int i = 0; i < 10; i++)
    {
        var watch = Stopwatch.StartNew();
        HtmlEntities.Lookup("rfloor");
        watch.Stop();
        Console.WriteLine(watch.Elapsed);
    }
}

Here is a gist of the code behind HtmlEntities, which contains a single method: https://gist.github.com/jamesqo/3331a02f8168a6c782853556ac8f19e5

For some reason when I run the code above, I consistently get a very high number on the first iteration, and then much smaller times on the next ones. For example, here is a sample output to the console after I run this:

00:00:00.0348343
00:00:00.0000016
00:00:00.0000010
00:00:00.0000016
00:00:00.0000016
00:00:00.0000010
00:00:00.0000010
00:00:00.0000016
00:00:00.0000016
00:00:00.0000010

Can anyone explain why this is happening? As far as I can see, the method is just a gigantic switch-case that maps particular strings to chars. Does it have something to do with having to calculate the hash code of the string on the first try, and then on subsequent iterations it is cached?

For comparison, here is an alternative version of HtmlEntities that initializes a gigantic Dictionary at runtime and then looks the values up from that. Using that implementation, the first iteration is much much faster, however subsequent iterations are not so fast. Here's a sample output when the app is run using that one:

00:00:00.0000329
00:00:00.0000027
00:00:00.0000021
00:00:00.0000021
00:00:00.0000021
00:00:00.0000021
00:00:00.0000021
00:00:00.0000021
00:00:00.0000021
00:00:00.0000021

Can somebody explain this phenomenon and why it is happening? Thanks.

James Ko
  • 32,215
  • 30
  • 128
  • 239
  • 2
    Could it be the cost of [JIT compilation](https://en.wikipedia.org/wiki/Just-in-time_compilation)? – Yacoub Massad Apr 13 '16 at 21:49
  • [Branch prediction](http://stackoverflow.com/a/11227902/3410196)? – Alexander Derck Apr 13 '16 at 21:51
  • @JeroenVannevel That still doesn't explain why the second implementation is so much drastically faster than the first... – James Ko Apr 13 '16 at 21:53
  • @JamesKo There's no point in discussing such minimal performance differences when the benchmark is so unreliably performed. The effect you ask about (first iteration being much slower) is perfectly explained by JIT compilation. If you want to know why one implementation seems better (after a proper benchmark) then there are still so many more reasons which I would argue probably falls outside of the scope of SO anyway if there's no prior research done from your end that pinpoints it somewhat. The least you should do is look at IL and assembly results to see what might cause it. – Jeroen Vannevel Apr 13 '16 at 22:02

0 Answers0