Add ability to downsize caches in response to a max-memory signal #443
Conversation
|
Looks good! I'm worried about caches size = 1. I experimented with |
|
@vasily-kirichenko Right now I can't even edit at all when this kind of memory usage is reached - all of Visual Studio grinds to a halt. So even if VFPT features stopped working this would actually still be an improvement, though far from ideal Thanks for trying it out! If CI produces a VSIX I can use with this included I'll give it a go too. |
|
@dsyme I'm afraid you have to publish new FCS NuGet, otherwise CI cannot build VFPT. |
Add ability to downsize caches in response to a max-memory signal
|
CI seems to slow at the moment, I've shared the VSIX here https://docs.google.com/uc?authuser=0&id=0B8HLQUKik9VtS0RTN1F3NzFJbEE&export=download |
Make FCS automatically downsize caches when a maximum allocated memory threshold memory is reached.
This is somewhat experimental but may be the best solution to the "Visual Studio grinds to a complete halt" issue discussed here: fsprojects-archive/zzarchive-VisualFSharpPowerTools#1160 (comment)
The default threshold is 1.7GB of allocated managed memory in a process. This corresponds to a managed memory size of around 2.5GB. When this happens, the "strong" values for keeping background project builds are reduced to size 1 for the remainder of the lifetime of the FSharpChecker object. In practice this will still make Visual Studio F# Power Tools usable, but some operations like renaming across multiple projects may take longer.
Reducing the FCS strong cache sizes does not guarantee there will be enough memory to continue operations - even holding one project strongly may exceed a process memory budget. It just means FCS may hold less memory strongly.