I haven't closed VS in ~ 24 hours as I tend to just leave it open when I'm not using it. The project isn't large by any means but it seems the NCrunch test runner memory isn't releasing as it seems to gradually increase in memory usage over time.
Right now I have 2 nCrunch.TaskRunner40.x86.exe *32 processes and the first has a memory (Private Working Set) of ~ 1,121,860 K and the second is using ~ 902,080 K. The visual studio devenv.exe memory usage seems reasonable for nCrunch & R# at around 443,500 K. Right now there's only 67 tests so I wouldn't think this would be a typical memory footprint. I have seen where there could be issues with lots of console output in the tests, and this may be related as is a project using codeDom. It's the same solution that I emailed earlier just a slightly newer revision if it helps you to see the project.
I'll leave the solution open for as long as it stays open so if you let me want me to grab information before I restart it.
Win7 64 bit, VS 2010 Premium, R# and nCrunch 1.38b.
Thanks,
Mark Smith
Remco NCrunch Developer
#1607
01 Apr 2012 20:56 UTC
Hi Mark,
When reading your thoughts about lots of console output, the first thing that this brings to mind is that you may be experiencing problems with heap fragmentation. NCrunch tends to store the console output for tests that have just been executed - in large chunks of allocated memory (if the console output is extensive). When they are deallocated, the chunks are not properly broken down by the garbage collector and the memory allocation becomes increasingly less efficient.
There may be things I can try to reduce this, but firstly it would be great if you could share some rough numbers for me to work with:
- How much code is in your solution? (i.e. sum of all your projects that are loaded into the test app domain)
- What is the approximate amount of console data emitted by all your tests for an entire run? (i.e number of chars)
Thanks!
Remco
When reading your thoughts about lots of console output, the first thing that this brings to mind is that you may be experiencing problems with heap fragmentation. NCrunch tends to store the console output for tests that have just been executed - in large chunks of allocated memory (if the console output is extensive). When they are deallocated, the chunks are not properly broken down by the garbage collector and the memory allocation becomes increasingly less efficient.
There may be things I can try to reduce this, but firstly it would be great if you could share some rough numbers for me to work with:
- How much code is in your solution? (i.e. sum of all your projects that are loaded into the test app domain)
- What is the approximate amount of console data emitted by all your tests for an entire run? (i.e number of chars)
Thanks!
Remco
According to Code Metrics window in VS Lines of Code for the test project is 383 lines, The Test Project is 377 lines. There's only about 10 classes total. It's a pretty small project thus far. The tests don't actually output anything using to the console, but the assertions are often based on string contents and comparisons. For instance Assert.IsTrue(Result.Contains("String To Look For")); is a common assertion. On any given test, figure about 50 tests the strings being worked with are no longer than 50 lines/1000 characters per test.
Edit: There is one condition I found that will generate output to the console in the tests that was embedded in the code. This would only happen when the code is in a bad state and generating erroneous output which would flag the tests as failed. I can remove this console call if that you think that would fix the issue.
Edit: There is one condition I found that will generate output to the console in the tests that was embedded in the code. This would only happen when the code is in a bad state and generating erroneous output which would flag the tests as failed. I can remove this console call if that you think that would fix the issue.
Edited 01 Apr 2012 22:40 UTC
Remco NCrunch Developer
#1615
02 Apr 2012 21:30 UTC
Thinking this through, I suspect that the processes running with high memory usage are likely to be the processes used to execute builds. I'll have a look to see if I can do anything about this, but meanwhile you can probably work around the issue by just punching the NCrunch 'reset' button every few hours to recycle these processes.
Post a reply
Log in to reply.