tons of memory used after 3 clicks

[ctaggart]

After 3 clicks or so, VSCode with Ionide is using 1.2 GB of memory with most of it used by FsAutoComplete. This is a pretty basic .NET Core Project that targets net46. Memory usage seems a bit too high. Anything I can do to help get this back down?

bundle source linked pdb files for:

• Argu use SourceLink 2 fsprojects/Argu#97
• Dotnet.ProjInfo
• Dotnet.ProjInfo.Helpers
• FParsec use source link instead of separate symbols stephan-tolksdorf/fparsec#23
• FParsecCS use source link instead of separate symbols stephan-tolksdorf/fparsec#23
• FsAutoComplete.Core source link the pdb files #268
• FsAutoComplete.Core.VerboseSdkHelper source link the pdb files #268
• fsautocomplete source link the pdb files #268
• FSharp.Compiler.Service pack source linked pdb files fsharp/fsharp-compiler-docs#842
• FSharp.Core ship FSharp.Core.pdb files dotnet/fsharp#294
• FSharpLint.Core
• Newtonsoft.Json enable source linking JamesNK/Newtonsoft.Json#1555
• Priority Queue
• Sln
• Suave enable source link SuaveIO/suave#599

[enricosada]

Hi @ctaggart can you please add info about:

• OS (and mono version if osx)
• fsac runtime type: if netcore or net (the fsacRuntime setting in ionide)

about Memory usage seems a bit too high atm is not optimized for low usage. adding some perf dump/hints may help.

[ctaggart]

@enricosada I've very curious how you would go about troubleshooting this. I created the dump using Visual Studio 2017 by attaching to the process and then selecting Debug > Save Dump As.

https://1drv.ms/u/s!AgzKxNqZP8-4gZwrlWI7zid3N6KJMw

I'm running Windows 10.

cmd /c ver
Microsoft Windows [Version 10.0.16299.125]

I haven't changed the default Ionide configuration:

  "FSharp.fsacRuntime": "net",

Should I try netcore?

Don't you need the pdb files to troubleshoot?

When I open up the dmp file and select an FsAutoComplete StackFrame, it complains that the pdb is not found.

What about shipping source linked portable pdb files with Ionide? Currently Ionide takes up 22.6 MB on disk for me. Another few megabytes more of disk space would not hurt.

[enricosada]

mhh.. yes we miss pdb.
some more MB doesnt matter, if helps. dunno why ionide exclude that, i'll check

we can add portable pdb too afaik.
but if you can send a PR for source linked portable pdb files for FSAC, a lot better

atm probably we need to run FSAC built from source to get the dump, and mean is bad

[enricosada]

Another stuff, is to start a discussion about how to improve perf.
we need to add metrics somehow, and make it easier to gather it

[ctaggart]

The netcore libraries for Ionide include some of the pdb files. I'll try to increase the number and get them source linked. I'll also switch over to using the netcore version.

SourceLink 2 requires .NET Core project files, so my PR for this repo will only be for the netcore projects.

[tboby]

I've been having great problems with the memory usage of FSAC on my slow ubuntu laptop. I'm using VSCode and FSAC is using several times more memory than any other process on my machine.

I'd be happy to try to help gather usage data.

[ctaggart]

I've got pull requests open for the projects, but meanwhile, I've started making builds using appveyor for the projects and posting to myget:

https://www.myget.org/feed/Packages/sourcelink

So far I have Newtonsoft.Json & FParsec.

[chinwobble]

What's the best way to measure performance and integrate into the CI process so that we can check for performance regressions?

Does a new project with benchmarkDotNet (or similar) need to be added with the build.fsx updated?

[ghost]

I am not sure how helpful this is, but I took a heap snapshot of fsautocomplete when opened on a basic enough fsproj, it seems that out of the 1.5gb, FsAutoComplete holds onto about 800mb, a very very naive guess shows the following:

ADDR   COUNT        SIZE    CLASSNAME
XX     3439        82536 Microsoft.FSharp.Core.FSharpOption`1[[FsAutoComplete.DraftToken, FsAutoComplete.Core]]
XX     3772       120704 System.Tuple`2[[Microsoft.FSharp.Collections.FSharpList`1[[FsAutoComplete.DraftToken, FsAutoComplete.Core]], FSharp.Core],[Microsoft.FSharp.Core.FSharpOption`1[[FsAutoComplete.DraftToken, FsAutoComplete.Core]], FSharp.Core]]
XX     3439       137560 FsAutoComplete.DraftToken
XX    10245       327840 Microsoft.FSharp.Collections.FSharpList`1[[FsAutoComplete.DraftToken, FsAutoComplete.Core]]

Which seems like some pretty large numbers, however this code appears to come from the Lexer, so this makes sense. It will be interesting to see if fsharp/fslang-suggestions#648 will eliminate some of this allocation overhead (there is a fair bit of string copying happening inside LexerSymbol).

However, this doesn't really account for some other performance situations where fsautocomplete peggs the CPU after a few hours of use (hard to reproduce), I haven't finished testing it (and am very cautious to suggest this is a fix), but it looks like one of the culprits may be here https://github.com/fsharp/FsAutoComplete/blob/d397eb6f6734c833d66b5c6e48eb032f4d2d320a/src/FsAutoComplete.Core/Commands.fs#L39 , which appears to leak AsyncContext into the environment (from memory it needs to have a return inside async block).

[ghost]

It appears the latest version of ionide, which packs the latest version of FAC has improved the memory situation on my system. Can others try and report findings?

[tboby]

@abk-x no improvement for me on linux. My computer eventually freezes due to the steady increase in FSAC memory/cpu usage! I've resorted to having a timer that reminds me to kill the process every 20 minutes.

[cartermp]

@ctaggart I recommend download PerfView: https://github.com/Microsoft/perfview/blob/master/documentation/Downloading.md

You can use it to run a collection after you've opened your project(s) in VSCode:

After ~30 seconds or so of using Ionide such that it will start using lots of memory or otherwise causing perf problems, you can stop collecting and analyze the trace. Here's an example of one I recently did.

• Take a look at GC status to see if there is anything interesting like Gen2 collections, or large amounts of Gen1 allocations

• Check out the GC Heal Alloc Ignore Free, with no grouping. Select the FSAC process. Look for Large Object; if it's anywhere in the top ten then there's a legit issue:

(or in this case, range was number 2, yet it's a small struct and shouldn't be showing up here)

You can drill into a specific call to see if it's the primary contributor. In the case of my trace, ByteBuffer.Ensure in the F# compiler was the primary culprit for LOH allocations.

You can also look at CPU stacks to look at where relative CPU time is being spent. In the case of my trace, there were two strange entries:

Combined, these made up ~5% of total CPU time, yet the utility they offered me (suggested names for a compile error) was very small because I was just writing code slowly enough to trigger a compile error here and there.

The goal in an exercise like this is to determine:

• Is there anything in FSAC specifically that is contributing to a slowdown? If so, then there's something actionable that can be done in this repo.
• Are perf problems primarily coming from F# compiler internals? If so, is each operation relatively cheap, but they keep getting re-run? If so, is there something in FSAC like a missed cache that can be fixed? If not, then an issue can be filed on the F# compiler repo.

[baronfel]

We also need to look at doing another release of FSharp.Compiler.Service. The most recent is 4 months old per nuget, and I know the team has put in some good perf work since then.

[cartermp]

Not sure which version Ionide uses, but IIRC @Krzysztof-Cieslak does build the package from the VisualFSharp repo, so it may not be horribly out of date

[baronfel]

Ionide's using master of this repo, so the same 25.0.1 version that's ~4months old.

  remote: https://github.com/fsharp/FsAutoComplete.git
     (f4e29b59782c38a3c7a3bd9151b08e503ec01e69)
      build: build.cmd LocalRelease
      os: windows
     (f4e29b59782c38a3c7a3bd9151b08e503ec01e69)
      build: build.sh LocalRelease
      os: mono

[Krzysztof-Cieslak]

Ok, let's close this one. Ofc, memory usage is still high, but anything in this thread is outdated. If anyone has actionable reports about memory usage please create separate issues, preferably with PerfView analysis.