The tracing part of CodeTrack v126.96.36.199 has been completely rewritten in order to reduce the profiling overhead as much as possible, while still giving you the option to enable certain measurements if you need them.
By doing this the profiling overhead has been greatly reduced. In this post I’ll show you exactly how much faster CodeTrack has become and also what the effects of the different settings are on the overhead.
The Sample Code
For measuring the overhead I just wrote a very simple console app :
Nothing to fancy, as you can see 🙂 It’s just a method being called a gazillion times.
If I run this app I get:
So you can see that excuting MethodB 1 time takes 945/50 = 18,9 ms. We’ll use this as our baseline.
V188.8.131.52 vs V184.108.40.206
Just to prove I’ve been doing some useful work, let’s trace this with V220.127.116.11:
Since this took ages, I didn’t wait for the app to finish, but you can see now this takes about 8100 ms per iteration.
If do the same thing with V18.104.22.168 we get:
That’s 391 ms per iteration (so 20 times faster, not bad 🙂 )
Options, options, options
In the advanced expander in the tracing options you can pick exactly the options you want for your tracing session (A blogpost about the differences will follow soon).
In this summary I’ll show you the same measurement for different settings:
No options enabled: 391ms
Hi resolution: 466ms
Hi resolution + thread cycles: 509ms
Thread cycles: 454ms
Hi resolution + compensation: 565ms
Timeline + Hi resolution: 6903ms
Another (non-free) famous profiler*: 427ms
*I don’t want to start throwing mud here, so I’ m not going to tell which one it is. Live and let live! I just want to prove that CodeTrack has grown and can deliver professional results.
Of course these measurements depend heavily on the kind of code you are executing, but I think it gives you an idea about how performant CodeTrack has got.
Don’t take my word for it, go get your free copy and check it out for yourself at