AltCover.prepare uses GB of RAM

[TclasenITVT]

Hello Steve

after expanding my FSharp Project a bit generating the CodeCoverage Report now takes up all the system memory it can get. My System has 8GB Ram and after taking up 7 GB I killed the process. Even with the --single flag specified the memory consumption does not reduce. I use the newest Version of AltCover 5.2.667 but I also had the same Problem with Version 5.2.665.
The last build that didn't run that long(using 5.2.665.) was before I added Records with Interfaces and DUs plus Interfaces.
I would have thought that this would be a standard Fsharp style programm.
I excluded xunit and Moq.
Is there another way of reducing the memory usage?

[SteveGilham]

The changes between 5.0.665 and 5.2.667 have been peripheral, mostly API related, so I would not expect any noticeable change in the behaviour of the main instrumentation and reporting stages. The easy wins in memory reduction were part of the 4.0.659 release; currently the big items in memory will be the XML report, and a sequence point to visit count dictionary (plus any tracking data from the --callContext option, which has the biggest potential to bloat the data).

How large is your project? One useful measure would be the size of the XML report file generated in the instrumentation phase, and memory use will scale with that size.

[TclasenITVT]

The last successfully generated xml report was 111kb.

[SteveGilham]

Interesting. That's quite small. By comparison, the AltCover self-test (instrumenting and running its own unit tests) generates a 2Mb XML report (for 4400 coverable code points), and yet the AltCover runner stage only consumes a few 10s of Mb memory with --single in place.

I think that gives me a first place to start instrumenting for memory use, though.

[SteveGilham]

Scratch that -- I suddenly notice the .prepare in the issue title.

What's in memory in the prepare phase are the XML report and Cecil representations of the assemblies being modified; nothing's been visited yet, so the --single flag hasn't come into play. Mentioning that had sent me haring down the wrong path.

Again, the self-test doesn't spike significantly in memory at any point. This gives me a different place to start looking, though.

[SteveGilham]

After some investigation of the prepare operation, and not getting a test set above the 10s of Mb at maximum, it occurred to me to try again with Server GC enabled, which essentially turns GC off until memory pressure forces collection. At that point I logged memory usage into the low hundreds of Mb during instrumentation for a moderately sized test, because no memory got recycled during the run.

If there are "enough" assemblies being instrumented, working under Server GC would be one possible mechanism for leaving unrecycled memory in process.

[SteveGilham]

I just had an instance of this behaviour, though that was after updating a sample program to FSharp.Core 4.7; though that one looked like an unterminated recursion.

[SteveGilham]

The latest build of master resolves the specific memory grabbing I was seeing, which was related to branch coverage of a loop -- not 4.7 compilation specific, but due to the way some of the library code had changed between releases. It wouldn't hurt to give this build a try if you are still seeing this issue.

[SteveGilham]

Release 5.3.688 has the fix for the issue I found. Does this resolve your issue?