It's now been over 13 months since the first beta of NCrunch went up on this website.  It's very satisfying to see how far the tool has progressed in its features, speed and stability.  More than any other project I've worked on, NCrunch has so clearly demonstrated how effective an iterative and exploratory approach to developing software can be.  I want to thank everyone for their efforts in helping to report problems and suggest the features that have made NCrunch the success it is today.  Without a doubt, the best way I can think of to offer my gratitude for this is with another release of NCrunch!

The original plan for 1.40b was to release it somewhere in July, though after taking a good look at the huge list of improvements and fixes included, and considering that the tool was looking nice and stable, I decided to bring the release forward to share some of the love a bit earlier :)

The main focus for the 1.40b release was on stability, performance, and memory efficiency.  As such, I don't have as many shiny screenshots to help fill out this blog post, but I hope that you'll soon agree that this release is a significant improvement over 1.39b and well worth the time taken to download and install.

Let's see what 1.40b has to offer ...

Performance Improvements

1.40b contains a number of changes to improve performance around the internal processing queue and test prioritisation.  These improvements make NCrunch significantly more intelligent in managing CPU resources for tests that are sitting in the pipeline, reducing background CPU load while also ensuring test results show in the IDE much faster than before.

A major change has also been introduced to the way in which NCrunch resolves assembly references inside its test execution environment.  Previous versions of NCrunch would always pre-load ALL referenced assemblies into the task runner before any tests were executed.  The reason for this had much to do with control over the environment - NCrunch needed to ensure that the correct referenced assemblies were loaded into the test environment and prevent the CLR from pulling up the wrong files by probing.

The assembly referencing model in 1.40b is now reliable enough that assembly references can be loaded on-demand rather than upfront.  The impact of this can't be understated - one of my test projects had an improvement in test response time from around 15s down to 4s.

If for any reason you need to restore the up-front loading of referenced assemblies, a new project-level configuration option has been introduced under the name 'Pre-load assembly references into test environment'.

Improved Memory-Efficiency

Since its first release, I've constantly received complaints about NCrunch being particularly memory-hungry.  The reasons for this have always been varied and while not everyone has experienced problems, there has always been a long term goal to keeping memory utilisation as low as possible.  By the time I began working on 1.40b, it had become clear that most of the memory related problems reported were related to data being held from executed tests and the memory allocated by the tests themselves.  For 1.40b I took a bit of a difference in focus on tackling memory efficiency by targeting user-allocated memory and finding better ways to reduce its lifetime.

NCrunch 1.40b introduces better handling of tests with large amounts of trace output, by introducing more efficient storage of this trace output.  The difference this makes is quite dramatic but not altogether surprising.  Just imagine a test that dumps 30M of data out to the console, then imagine the logic of this test being used for 100 other tests that are just like it.  That's 3GB of data being stored in memory!  This change alone reduced overall VS memory utilisation by as much as 50% on many of my test solutions.

Something else that has also made a big impact on memory utilisation is NCrunch's process pooling.  To avoid needing to kick off test runners for every test execution task, NCrunch has always pooled task runner processes for later use.  While this has helped with performance, it isn't great for keeping memory usage low.  Tests will often allocate large amounts of static data existing throughout the lifespan of the test process, and you can imagine how this could become a problem when there may be anywhere up to half a dozen execution processes that have all run tests before they just sit around waiting.

1.40b introduces a range of changes to the process pooling to make it more efficient and intuitive:

- The 'Process pool size' configuration option has been replaced with 'Max test runner processes to pool'.  The new configuration option applies only to test runner tasks and is now used to specify the maximum number of test task runners that can sit idle in a pool at any one point in time.  The new configuration option is exclusive of processes required to support the number configured in the existing 'Max number of processing threads' configuration option.

- A new configuration option, 'Terminate test runner tasks when all test execution is complete', has been introduced.  This option will limit the process pooling so that it will no longer happen after all tests have finished executing.  A side-effect of this is that the UI options to 'Run a test using an existing task runner process' will no longer be available (as the existing task runner processes have already been terminated).

- A new step has been added to the configuration wizard allowing you to choose between test execution speed and memory-efficiency.  This step will set the above configuration options according to your choice.

- The EXE names for NCrunch's task runner processes have been changed so they now reflect the type of task being performed.  Build tasks will be run in a BuildHost, while test tasks will now be run in a TestHost.  This should make it easy to tell the tasks apart and give you more information about what NCrunch is doing.

New Exception Stack Navigation Popup Window

The ugly and unnecessarily complex exception popup window has had a bit of a revision in 1.40b.  Since it was introduced, a number of people have described this popup as being difficult to read and understand.  The new version of the popup more closely resembles a traditional stack trace and also has an extra link to show the selected test in the Tests Window for closer inspection.

Fixes, Fixes, Fixes!

And of course, 1.40b contains a list of 35 distinctive fixes and compatibility improvements.

What are you waiting for?

Go grab 1.40b!