TL;DR:
* Having a code-injecting profiler attached slows down process cold-start times, even if the profiler doesn't inject any code.
* I want a way to see which tests are still utilizing the Just Mock Profiled Mocking features and which are utilizing the regular mocking features.
The long version:
Just Mock has one set of features that are are accessible without their profiler. It has another set of features that require their profiler attach in order to function. I inherited a code base a couple years ago and began using Just Mock to improve test coverage while I slowly worked through refactoring various parts of my application to be more testable without the need for profiled mocking (dependency injection, loosely coupled eventing system, etc.). I am at the point where I would like to get an idea of how many of my tests still require the profiling features of Just Mock. In order to do that, I need to be able to turn the profiler off temporarily so I can assess the situation.
Also, application cold start times are significantly higher with a code-injecting profiler attached than they are without. This is due to the nature of how the CLR Profiling API works and unfortunately, there is nothing that Telerik or NCrunch can do to resolve it. As an example, an application that normally loads in 1-2 seconds and hits ~15,000 methods (mostly Framework) on my machine takes ~10-12 seconds if a code-injecting profiler is attached. I have other projects I work on that do not require any profiler in order to run yet I still utilize the non-profiling features of Just Mock. I would like NCrunch to be able to execute those test projects faster. Unfortunately, because NCrunch automatically attaches the profiler to any project that utilizes Just Mock (whether it needs the profiled mocking or not), I suffer the performance hit for most of my projects.
I can fully appreciate the desire to have Just Mock work out of the box for users and I am not suggesting that that change, it definitely helped me get NCrunch up and running quickly. However, I would like some way to turn it off on both a temporary basis and on a permanent per-project/solution basis for the two reasons listed above.
Additional information:
For the curious, the reason attaching a code injecting profiler hurts cold start times is because the CLR is unable to utilize the pre-JIT-compiled .NET Framework class libraries. When you install the .NET Framework, it pre-compiles the entire framework to improve cold start times, as well as to provide some other runtime performance benefits (http://msdn.microsoft.com/en-us/magazine/cc163610.aspx). In order for a code-injecting profiler to work, every method has to go through the JIT-compilation process before it can be used, to give the profiler an opportunity to inject the code it wants into methods at runtime. Because of this, the pre-compiled libraries can't be used and while the CLR's JIT-compiler is fast, it still takes time to JIT-compile every method hit in the .NET Framework.
