High CPU in fsautocomplete.dll

[Bananas-Are-Yellow]

Version

Ionide v7.31.1

Dotnet Info

.NET SDK:
 Version:           10.0.103
 Commit:            c2435c3e0f
 Workload version:  10.0.102
 MSBuild version:   18.0.11+c2435c3e0

Runtime Environment:
 OS Name:     pop
 OS Version:  24.04
 OS Platform: Linux
 RID:         ubuntu.24.04-x64
 Base Path:   /usr/lib/dotnet/sdk/10.0.103/

.NET workloads installed:
 [wasm-tools]
   Installation Source: SDK 10.0.100
   Manifest Version:    10.0.102/10.0.100
   Manifest Path:       /home/david/.dotnet/sdk-manifests/10.0.100/microsoft.net.workload.mono.toolchain.current/10.0.102/WorkloadManifest.json
   Install Type:        FileBased

Configured to use workload sets when installing new manifests.

Host:
  Version:      10.0.3
  Architecture: x64
  Commit:       c2435c3e0f

.NET SDKs installed:
  10.0.103 [/usr/lib/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 10.0.3 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 10.0.3 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  DOTNET_BUNDLE_EXTRACT_BASE_DIR           [/home/david/.cache/dotnet_bundle_extract]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Steps to reproduce

The problem seems to occur when I activate a tab for any source file in a particular project, or a tab for a higher level project that depends on that project. The CPU goes high and stays high.

The project is called Client, so you can find it in the provided trace logs.

Unfortunately, it is not open source, and it may become commercially valuable at some point, so I'm not happy to provide the source itself, but I can try experiments to track down the problem.

Details

I expect the CPU to go up for a second or two while FsAutoComplete does it's parsing, but it stays high indefinitely. VSCode is still usable but my fan is blowing. If I close the source file tab and restart VSCode, the CPU is back to normal, but then when I open the file again, the CPU goes high and stays high. It is typically over 20%, but sometimes only around 10%.

The memory is also high, around 1.2GB while I was watching it in the System Monitor.

> ps -p 369018 -o %mem,cmd
%MEM CMD
 2.1 /usr/bin/dotnet /home/david/.vscode/extensions/ionide.ionide-fsharp-7.31.1/bin/net9.0/fsautocomplete.dll --verbose --state-directory /home/david/.config/Code/User/workspaceStorage/29da2c99ab63e84b9115ef46bac97411/Ionide.Ionide-fsharp

In case any of this helps:

> fastfetch
             /////////////                 david@mini-pc
         /////////////////////             -------------
      ///////*767////////////////          OS: Pop!_OS 24.04 LTS x86_64
    //////7676767676*//////////////        Host: AI Series (1.0)
   /////76767//7676767//////////////       Kernel: Linux 6.18.7-76061807-generic
  /////767676///*76767///////////////      Uptime: 1 day, 16 mins
 ///////767676///76767.///7676*///////     Packages: 1817 (dpkg), 35 (flatpak-user)
/////////767676//76767///767676////////    Shell: fish 4.5.0
//////////76767676767////76767/////////    Display (DELL U2725QE): 3840x2160 @ 1.55x in 27", 120 Hz [External]
///////////76767676//////7676//////////    DE: COSMIC
////////////,7676,///////767///////////    WM: cosmic-comp (Wayland)
/////////////*7676///////76////////////    Theme: Yaru [GTK3]
///////////////7676////////////////////    Icons: Yaru [GTK3]
 ///////////////7676///767////////////     Cursor: Adwaita
  //////////////////////'////////////      Terminal: cosmic-term
   //////.7676767676767676767,//////       CPU: AMD Ryzen AI 9 HX 370 (24) @ 5.16 GHz
    /////767676767676767676767/////        GPU: AMD Radeon 890M Graphics [Integrated]
      ///////////////////////////          Memory: 14.21 GiB / 60.44 GiB (24%)
         /////////////////////             Swap: 0 B / 20.00 GiB (0%)
             /////////////                 Disk (/): 194.66 GiB / 1.78 TiB (11%) - ext4
                                           Local IP (enp196s0): 192.168.1.213/24
                                           Locale: en_US.UTF-8

Logs

I set tracing to verbose.

F#.log
Ionide.log

Checklist

• I have looked through existing issues to make sure that this bug has not been reported before
• I have provided a descriptive title for this issue
• I have made sure that that this bug is reproducible on the latest version of the package
• I have provided all the information needed to reproduce this bug as efficiently as possible
• I or my company would be willing to contribute this fix

[Bananas-Are-Yellow]

Further information, in case it helps:

• The app is a Bolero app, but I cannot reproduce the problem with the dotnet Bolero template.
• The app is a PWA, and the Client project is WebAssembly.
• I am using .NET 10 and some of the new facilities in F# 10.

[Krzysztof-Cieslak]

Hey, thanks for detailed report.

• How big is the project?
• Are you using a lot of Statically Resolved Type Parameters or Type Providers?

[Bananas-Are-Yellow]

The Client project has 12 F# source files. There are 5 projects in all, and the largest has 15 source files (that project does not show the problem).

Is there a quick way to find all Statically Resolved Type Parameters? It's not something I have consciously made big use of. I do have some functions, which I think fall into this category. They are defined in my Foundation project for other projects to use. For example:

[<AutoOpen>]
module Core =
    module P = LanguagePrimitives

    /// The mid-way between two values.
    let inline mid a b = P.DivideByInt (a + b) 2

    /// Tests whether a value is within the specified range, including those limits.
    let inline within st en value =
        P.GenericLessOrEqual st value && P.GenericLessOrEqual value en

The mid function is only used in one place, and the within function is used in 14 places, but neither is used in the Client project.

As for Type Providers, I haven't written any myself. Bolero provides HTML Templates, which I use. I have 5 HTML templates.

Here is my paket.dependencies file, so you can see what packages I am using, in case any of those might be of interest.

source https://api.nuget.org/v3/index.json

// Only the target frameworks that are used in projects.
framework: auto-detect

// Do not extract into the "packages" folder but use a globally shared directory.
storage: none

nuget FSharp.Core
nuget FSharp.SystemTextJson
nuget FSharpPlus
nuget WebDav.Client
nuget Microsoft.Extensions.Http
nuget Microsoft.AspNetCore.Components.WebAssembly
nuget Microsoft.AspNetCore.Components.WebAssembly.DevServer
nuget Microsoft.AspNetCore.Components.WebAssembly.Server
nuget Microsoft.AspNetCore.Components.WebAssembly.Authentication
nuget Microsoft.AspNetCore.Http.Abstractions
nuget Microsoft.Authentication.WebAssembly.Msal
nuget Bolero
nuget Bolero.Build
nuget Bolero.HotReload
nuget Bolero.Server
nuget Bolero.HotReload.Server
nuget Serilog.AspNetCore
nuget Serilog.Sinks.BrowserConsole
nuget Serilog.Expressions
nuget Serilog.Sinks.Seq
nuget Serilog.Extensions.Logging
nuget Google.Apis.Drive.v3
nuget Blazored.LocalStorage
nuget Blazored.SessionStorage
nuget Dropbox.Api

[Bananas-Are-Yellow]

Forgot to mention that those 5 HTML templates I use are in the Client project. I don't use HTML templates in other projects.

The dotnet Bolero project template also uses an HTML template type provider, but, as I mentioned, I was unable to reproduce the high CPU problem with that code.

[github-actions]

🤖 This is an automated response from Repo Assist.

Worth noting: Bolero HTML Templates are type providers — specifically, they use Bolero.Template which is a provided type that reads the HTML file at design time. You mentioned "I haven't written any myself" and listed 5 HTML templates — those templates are type providers from FSAC's perspective.

This is very relevant to the maintainer's question. Type providers run user code in-process inside the compiler/FSAC to compute types, and can consume significant CPU if they:

• have slow file I/O
• invalidate frequently (e.g. when any F# file in the project is re-checked)
• are re-evaluated on every keystroke

The Client project containing those 5 HTML templates would trigger all of them on every background type-check cycle. If Bolero's template type provider is doing repeated file reads or heavy work, that could explain why CPU stays elevated when that particular project's files are open.

To confirm, you could try temporarily removing the Bolero.Build / Bolero.HotReload packages or replacing the templated components with plain Bolero HTML DSL equivalents and see if the CPU issue disappears — that would isolate whether the type providers are the cause.

Generated by Repo Assist

To install this workflow, run gh aw add githubnext/agentics/workflows/repo-assist.md@b0e9cfd3a20372ce7fe0462bb7bbca2272df4a88. View source at https://github.com/githubnext/agentics/tree/b0e9cfd3a20372ce7fe0462bb7bbca2272df4a88/workflows/repo-assist.md.

[Bananas-Are-Yellow]

The F#.log file I attached contains many type provider errors for one particular file, Dialogs.fs. I will investigate further.

[Krzysztof-Cieslak]

Also CC: our local performance magician - @TheAngryByrd

[Bananas-Are-Yellow]

The F#.log file I attached contains many type provider errors for one particular file, Dialogs.fs. I will investigate further.

I went through the same steps as before, only this time the F# trace output did not contain those errors referring to Dialogs.fs, and yet the high CPU problem still occurred when I switched to a tab for a source file in the Client project.

[Bananas-Are-Yellow]

In fact, the CPU does not stay high forever. After about 10 minutes, it goes back to normal.

I have a modern fast multi-core desktop computer.

[TheAngryByrd]

Couple things to try:

1. As @Krzysztof-Cieslak mentioned, type providers and SRTP are good things to investigate. Also an F# analysers
   • As there's evidence of a lot of errors coming from the type provider, try to "remove it" and see if that's the culprit Otherwise continue with these options:
2. Try the settings from Recommended settings for larger solution/projects
   • Usually the FSharp.codeLenses.references.enabled is the culprit since it's doing Find All References for everything
3. Try using OpenTelemtry export and see if there's any obvious place it's spending it's time
4. Similarly getting a dotnet-trace and using speedscope for flame graphs to point where it's spending it's time

[Bananas-Are-Yellow]

I tried setting FSharp.codeLenses.references.enabled to false, but this made no difference. Neither did any of the other recommended settings for large projects.