Thanks a lot, Remco,

We will proceed to order NCrunch very soon.

Not necessarily. It depends upon the extent to which you use it.

When you suppress code coverage for a region of code, NCrunch won't consider that code to be part of the code coverage calculation. So it won't consider this code to be covered or uncovered (it's considered 'not code').

So if you're doing this for large regions of code, it may have a slight impact on your overall metric, but it won't sway it much in one direction or the other.

Note that it is impossible for any tool to track code coverage without some level of performance impact.

Sorry, I'm not sure if I understand this question .. are you asking for a better way to find performance bottlenecks in your code?

Right now the best way I can suggest is to follow the yellow markers. Start from the top of the stack (at the test code), then follow them down through into your code to see where it's running slow. With the nature of your codebase, the likely loss of performance is from the markers themselves, and they'll detect their own performance cost.

We're presently working on a 'hot spots' view that will make this easier to do from a more global perspective. It's still experimental at the moment so I can't promise an ETA on this feature.

Something you can try is adjusting the performance display sensitivity setting to something a bit higher. You can tweak this so that it only shows yellow markers on lines of code that are extremely slow. This should reduce the clutter somewhat and help to focus on the areas where the performance is most in need of attention.

Start from the top of the stack, inside your test code. You can follow the yellow markers down through your code. This will give indication of where the code is slow inside your test, then through your production code.