F# requires more than 4GB of disk and/or memory to compile projects

[jzabroski]

F# is telling me there is not enough storage to finish compiling. It is not clear if this is RAM storage or disk storage, but I am assuming it is disk storage. However, given Visual Studio 2019 remains 32-bit, it is not unthinkable that F# is running out of 32-bit address space if hosted in-process as opposed to out-of-process with IPC message pump a'la Visual Studio Code.

Possibly related to #6866, #8044. For 8044, see also my comment there: #8044 (comment) for FS error numbers and error messages produced.

Repro steps

Provide the steps required to reproduce the problem:

1. Run Visual Studio 2019 (32-bit)
2. Run large F# (FSharpo.Core 4.7.1) and C# mixed use sln via Build Solution, several times, updating code in F# slightly each time. A trivial code update would be to use Resharper Rename refactoring on a C# method, compile, get F# errors due to C# Rename refactoring not peering through to F#, and then manually update those references in F# as well, and recompile. On last recompile, nasal demons emerge.
3. Solution should/may include a Resources assembly that contains basically just embedded resources with some resx files.

I cannot attach a repro given internal nature of project, but may be able to generate msbuild binary log files if helpful - need to reach out to my superior and possibly Legal to discuss. Would need to privately send to Microsoft developers, not upload to GitHub, in either case.

Expected behavior

1. No out of storage errors.
2. Specify if out of storage is disk or memory storage.

Actual behavior

Vague out of storage errors.

Known workarounds

Restart Visual Studio every ~15-30 minutes.

Related information

Provide any related information (optional):

• Operating system Microsoft Windows Server Datacenter Edition 2016 (Amazon Workspaces' largest instance size)
• .NET Runtime kind .NET Framework 4.8
• Editing Tools Visual Studio 16.5.4
• Free Disk Space: 5.58 GB on C Drive, 27.2 GB on D Drive (Visual Studio

[cartermp]

The errors you're seeing are just the message from a caught exception during .dll import. So unfortunately it's unclear if it's related to disk storage space or memory. I suspect it is more the latter, especially since R# is in use. R# balloons memory usage in the devenv.exe process, and with F# already being heavy as well, it's not too surprising that you're getting an OOM with two memory hogs basically fighting for a small address space.

The best way to tell for sure is to follow these steps when you notice memory being super high: https://github.com/dotnet/roslyn/wiki/Reporting-Visual-Studio-crashes-and-performance-issues#performance-issues

Using the second VS instance to record the first one and submitting the 30s or longer trace. This goes through a GDPR-compliant pipeline and is subject to other confidentiality rules we have in place. The trace itself won't contain any information other than where the compiler/tools spend their time and where memory gets allocated. Only with a trace can we have an indication as to what's happening.

[jzabroski]

Thanks - that's what I needed.

[jzabroski]

I'll close this and re-open if it is clear F# is at fault.