Timing your C# code

I’ve gotten a couple of emails on my recent column telling me that they couldn’t replicate my timings.

My first reaction was a sinking feeling in my stomach that I’d messed up the timings, but then a more rational idea occurred to me.

They were running from inside the IDE.

You see, whenever you do an F5 from inside the IDE, the IDE figures that you want to be able to debug your code, and therefore the JIT is put into debug mode, and you don’t get the fully optimized path.

This happens even if you are building in a release comparison.

IIRC, if you do a CTRL-F5, you don’t get this behavior, but it’s generally a better idea to do any timings outside the IDE, as the IDE may have other impact on your timings.

Comments (6)

  1. I think you mean CTRL+F5, which is "Start without Debugging" – SHIFT+F5 is "Stop Debugging."

  2. Jason Goodwin says:

    I remember the first time I was trying to time some worst case exception handling code. I was horrified at how long it took to do some "simple" things.

    Fortunately, after thinking about it for a while I ran it outside of the IDE and noticed the several orders of magnitude difference in timings.

  3. Don’t I remember that the license agreement for Visual Studio prohibits publishing benchmark results? That struck me as a bizarre (and probably non-enforceable) provision. What came over Microsoft’s lawyers that day?

  4. abdullah says:

    Timing your C# code

  5. abdullah says:

    Timing your C# code

Skip to main content