FCS uses too much memory

[vasily-kirichenko]

See the VFPT issue fsprojects-archive/zzarchive-VisualFSharpPowerTools#474 (comment)

@dsyme suggested to check these caches first: https://github.com/fsharp/FSharp.Compiler.Service/blob/master/src/fsharp/vs/service.fs#L2235

It's a very serious problem: it causes VS to quickly occupy RAM at the point when everything becomes unusable (~1.8...2.5GB) due to continuous garbage collecting. In practice it means I have to restart VS every 0.5..1 hour during the day as I working on a solution with 50+ F# projects. Even intensive working on VFPT more than an hour is impossible.

I created a console with which I can quickly (a minute) check that the bug is fixed or not.

Please, fix it ASAP.

[vasily-kirichenko]

I removed Add / Put calls on incrementalBuildersCache, braceMatchMru, parseFileInProjectMru, typeCheckLookup and typeCheckLookup2. It has not helped at all. The process memory increases linearly up to 6th GetAllUsesOfAllSymbolsInFile call, then stabilize, then decreases (from 260MB to 160MB), then increases again.

So I suspect there're more caches in FCS.

[dsyme]

I tried out the console app. However I don't see a leak as such - memory use rises but "Peak Working Set" stabilizes at around 400MB.

So is the issue "VFPT/FCS uses too much memory on big solutions" or "FCS has a leak"?

[vasily-kirichenko]

Yes, the memory use stabilizes after 5-6 runs. So, the issue is "FCS uses too much memory". I'm not sure about "big" solutions since it easily eats 2GB ram on the small VFPT one.

[vasily-kirichenko]

From VFPT point of view we wanted FCS to allocate fixed amount of memory for each project. It may discard caches for projects but it certainly should not keep some "historical" caches for projects. As a result, subsequent GetAllUsesOfAllSymbolsInFile calls (for example) with same ProjectOptions (with different LoadTime) should not increase memory usage at all. Simply speaking, FCS should keep any cached data by ProjectFullName key, not by ProjectOptions.

[dsyme]

OK, it would be good to identify a concrete memory bug or actionable saving.

FCS uses memory for sure. How much it uses will be largely dictated by a combination of

• project sizes (amount of source code, size of referenced DLLs, number of transitive project references etc.)
• the projectCacheSize parameter

I know you set the projectCacheSize parameter to 200 in order to improve cross-solution operations when there are lots of small projects. But always caching all projects (even 5-10) is to some extent asking for trouble - you're basically configuring FCS to say "memory be damned, cache everything!" :)

Does the memory use go so high when you set the number of cached projects back to something small (or disable the cache)?https://github.com/fsprojects/VisualFSharpPowerTools/blob/1333806aa332bc63293fd45740b7c3c830dd5e35/src/FSharpVSPowerTools.Core/LanguageService.fs#L125

I don't think there are any other signficant hidden caches involved, but I may be wrong.

[dsyme]

@vasily-kirichenko I'm trying to repro a situtation where VFPT uses 2GB+ when opening its own solution.

I did the following using the latest gallery published VFPT VSIX:

• opened "FSharpVSPowerTools.sln" (after building it)
• opened some random files and did "Shift-F12" on a number of symbols
• opened every F# file in the solution (actually both Xaml and F#)

At this point memory use was around 1GB. I then started randomly typing into a few F# files and it went up a bit more, to around 1.2GB.

I didn't do any debugging or the like.

Based on this it feels like this solution should always stay within a 1.5GB memory budget, and if it doesn't (e.g. after renaming files, or changing other project options, or doing other VS activities or ...) then that would be considered a bug (either in VFPT or FCS) or would would at least motivate better caching mechanisms/policy.

So it would be good to have a repro where this solution goes over 2GB (even with projectCacheSize=200=cache-everything)?

thx

[7sharp9]

Do we need to consider any of this for Xamarin Studio?

On 10 Jun 2014, at 09:42, Don Syme notifications@github.com wrote:

@vasily-kirichenko I'm trying to repro a situtation where VFPT uses 2GB+ when opening its own solution.

I did the following using the latest gallery published VFPT VSIX:

opened "FSharpVSPowerTools.sln" (after building it)
opened some random files and did "Shift-F12" on a number of symbols
opened every F# file in the solution (actually both Xaml and F#)
At this point memory use was around 1GB. I then started randomly typing into a few F# files and it went up a bit more, to around 1.2GB.

I didn't do any debugging or the like.

Based on this it feels like this solution should always stay within a 1.5GB memory budget, and if it doesn't (e.g. after renaming files, or changing other project options, or doing other VS activities or ...) then that would be considered a bug (either in VFPT or FCS) or would would at least motivate better caching mechanisms/policy.

So it would be good to have a repro where this solution goes over 2GB (even with projectCacheSize=200=cache-everything)?

thx

—
Reply to this email directly or view it on GitHub.

[dsyme]

@7sharp9 Eventually yes, though currently very large F# solutions are very, very likely to be using VS, and XS has fewer cross-solution features, and doesn't set projectCacheSize=200 AFAIK.

[dsyme]

@vasily-kirichenko I just read this comment (#158 (comment)). Agreed that FCS should not keep any out-of-date caches keyed on ProjectOptions (though I'm still unsure whether this is causing significant increased memory use)

[quasilord]

@vasily-kirichenko is right - there can be out of date entries in typeCheckLookup and typeCheckLookup2. I have a fix for this.

[vasily-kirichenko]

1. Load VFPT solution and Find all ResizeArray references. -> 980MB
2. Checkout some old commit which causes VS to ask you to "reload all". Do it. Find all refs again. -> 1.2GB
3. Repeat Bump version number #2 -> 1,45GB
4. Repeat -> 1.65GB
5. Repeat -> 1.9GB
6. Repeat -> 2.0GB
7. Repeat -> 2.1GB and VS freezes then redraws itself before shows Find refs results (I mean the plane main window border appears for a moment, that the usual one is drawn).
8. Repeat -> 2.3GB
9. Repeat -> While reloading the solution VS freezes again, but memory is shrunk to 2.1GB
   10 -> 2.2GB

(where colons are "private set" and "peak private set").

[quasilord]

Fixed in 0.0.52, published, see d6a0644.

@vasily-kirichenko Your test program now exhibits stable memory after one "w", but only if GC.Collect() is added after each "w"

    printfn "Got %d symbol uses in %O" uses.Length sw.Elapsed
    GC.Collect()
    GC.Collect()

There can still be "stale" entries in caches like typeCheck and typeCheck2 if projects are simply no longer in use (e.g. unloaded or renamed). Calling ClearLanguageServiceRootCachesAndCollectAndFinalizeAllTransients will flush these, along with everything else.

[dsyme]

@vasily-kirichenko Could you report results for your repro above, when using 0.0.52?