Hi,

1.40 and 1.39 are huge in memory consumption.

After a couple of hours all runners (4) are using each about 1GB RAM and more. Which leads to "not" enough memory in
my 8 GB System.

Runner is mostly MSpec, some NUnit Test.

Best Regards

I get the same issue with NCrunch for MSTest tests....



It's a real issue that's stopping general adoption at work - the 4Gb of memory in our workstations basically precludes us doing so - which is a shame, because it's a real help for a smooth workflow for developing software of the level of quality that we want.

Hi there,

I found v1.40b about 5 minutes after posting. :$

It's a LOT better - to the point of making NCrunch usable (I've already converted one colleague!), but still CAN generate quite high memory usage, particularly during the compilation phase.

From my (initial) testing, the test runners are taking about 60Mb (ish) each, whilst the build runners vary wildly up to 600Mb+ but then seem to settle back after - this if for the same solution as before, with an equivalent NCrunch configuration. I'm going to keep an eye on it tho'

It's not stopping me getting more memory from our Group IT Services!

Cheers

Yeah, BuildHost EXE's grow over time because there is some memory that isn't getting released by what looks like MSBuild functionality. it's basically 12 types that account for the majority of the memory, and 90% of those types are xml. Not sure what you are doing, but perhaps if it's something like a managed msbuild extension that is leaking the info due to it not being disposed, or something like that.

Here's an image of the memory dump I took, and as you can see at the bottom, most of the memory in the system is being used by those bottom 12 types, with almost everything else being very low memory usage.

http://i.imgur.com/d2Nl8.png

If you are unfamiliar with windbg, the first column is method table (basically the id for that type), second column is total # of instances, third column is total amount of memory those instances use in bytes, and fourth is of course the type.

For anyone interested, NCrunch 1.41b has just been released including a feature designed to limit the memory consumption by build processes. This should effectively solve the build process memory leaks described above, as NCrunch will automatically recycle these processes if their working memory becomes too large.