Hi, thanks for posting.

It's hard for me to give a straight answer on this, because over the years we've accumulated a number of different hosting implementations for all the variations platforms and framework versions we work with, and there are differences between them.

I think in some cases we may be using the server GC, but most consistently we've been careful to disable concurrent GC because of previous problems with heap corruption under some versions of .NET.

This is an area we need to be extremely careful when we make changes, because it can result in strange runtime exceptions appearing inconsistently in some environments. MS tend to treat the runtime and GC as being 100% stable and reliable with their release process, but my observation is that this is simply not the case. Runtime issues caused by the platform are extremely difficult to troubleshoot so we try to avoid them whenever possible.

When working on a typical ASP.NET or runtime application under .NET, usually these are settings you would freely adjust yourself to get the best result. If it caused instability or unexpected results, you'd just switch it back.

With the NCrunch project, it's not the same. When we change GC settings, it affects thousands of people working on a wide range of software in extremely complex environments. We can't guarantee that the result they see will be the same as ours, and if they raise issues with us it's very unlikely we'll be able to promptly identify the root cause of them.

So in this area we tend to prioritise stability over performance. If it isn't broken, we're not going to fix it.