Excessive CPU usage w/ reduced interactiveness on M1 Mac

[razzmatazz]

I am working on https://github.com/razzmatazz/csharp-language-server and with the latest fsac there appears to be an excessive CPU usage running for a very long time (10 mins +) ; the intectiveness of LSP server is significantly reduced too

dotnet stack report produces this:

• fsac-stack-report.txt
• fsac-stack-report-2.txt -- second trace after some time

most of code seems to be within fsharp.compiler -- and this is running even if I am not doing anything in the editor for a long time (5mins +) -- this is on a m1 mac (10 cores)

not sure if I should produce a profiler report or something?

[baronfel]

Yeah! A trace with a flamegraph or something would help us diagnose a root cause.

[razzmatazz]

this appears intermittent, does not happen after restart :/ -- will report with flamegraph or close later if I cannot reproduce this

[baronfel]

I want to say that I've felt but not measured similar when working on the F# compiler itself - I wonder if we're hitting some size threshold? Or if we're 'holding the APIs wrong'?

[razzmatazz]

here is dotnet trace collect -p <pid> --format=speedscope output for use with https://www.speedscope.app/

fsautocomplete_20220419_151039.speedscope.json.zip -- this is a trace running for about 16 secs

for now I cannot use fsac on battery since fsac kills it :)

[razzmatazz]

Curiously this only happens on M1/aarch64 and I cannot replacate this issue on my x86/AMD desktop Linux machine.

And then I cannot analyze dumps and do dumpasync on this arch because dotnet dump analyze core.file + dumpasync says "SOS does not support the current target architecture / arm64".

Closing, presumably things will get better with .NET 7 or later releases..

[baronfel]

interesting note - I've had reports that the background services are broken on M1, maybe this is the case for you? if you disable the background services do you see the same high usage?

[razzmatazz]

let me see..

[razzmatazz]

interesting note - I've had reports that the background services are broken on M1, maybe this is the case for you? if you disable the background services do you see the same high usage?

nah, same issue happens with no background service enabled, -- a lot of threads are busy in FSharp.Compiler.Service, like:

...
ass System.String>,class UnscopedTyparEnv,value class FSharp.Compiler.Text.Range,value class FSharp.Compiler.Text.Range,class Microsoft.FSharp.Core.FSharpOption`1<class System.Tuple`2<class Microsoft.FSharp.Core.FSharpOption`1<class Entity>,class Microsoft.FSharp.Core.FSharpRef`1<class ModuleOrNamespaceType>>>,class Microsoft.FSharp.Collections.FSharpList`1<class MutRecShape`3<class FSharp.Compiler.Syntax.SynTypeDefn,class Microsoft.FSharp.Collections.FSharpList`1<class FSharp.Compiler.Syntax.SynBinding>,class FSharp.Compiler.Syntax.SynComponentInfo>>)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations.f@846-29(class TcFileState,class ParentRef,class Microsoft.FSharp.Collections.FSharpSet`1<class System.String>,value class FSharp.Compiler.Text.Range,class TcEnv,class FSharp.Compiler.Syntax.SynModuleDecl,class Microsoft.FSharp.Core.Unit)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementNonMutRec@5373-26.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementNonMutRec@5373-29.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementNonMutRec@5373-31.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementsNonMutRec@5565.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElements@5690-3.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementNonMutRec@5459-19.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementNonMutRec@5373-29.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementNonMutRec@5373-31.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementsNonMutRec@5565.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElements@5690-3.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementNonMutRec@5518-23.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementNonMutRec@5373-29.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementNonMutRec@5373-31.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElementsNonMutRec@5565.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TcModuleOrNamespaceElements@5690-3.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.CheckDeclarations+TypeCheckOneImplFile@5914.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.ParseAndCheckInputs+TypeCheckOneInput@901-11.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.ParseAndCheckInputs+TypeCheckOneInput@829-16.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!FSharp.Compiler.ParseAndCheckInputs+TypeCheckOneInput@829-18.Invoke(value class System.Threading.CancellationToken)
  FSharp.Compiler.Service!Internal.Utilities.Library.Cancellable+toAsync@791-1[System.__Canon].Invoke(value class System.Threading.CancellationToken)
  FSharp.Core!Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvokeNoHijackCheck(value class Microsoft.FSharp.Control.AsyncActivation`1<!!0>,!!1,class Microsoft.FSharp.Core.FSharpFunc`2<!!1,class Microsoft.FSharp.Control.FSharpAsync`1<!!0>>)
  FSharp.Core!Microsoft.FSharp.Control.Trampoline.Execute(class Microsoft.FSharp.Core.FSharpFunc`2<class Microsoft.FSharp.Core.Unit,class Microsoft.FSharp.Control.AsyncReturn>)
  FSharp.Core!Microsoft.FSharp.Control.AsyncPrimitives.StartWithContinuations(value class System.Threading.CancellationToken,class Microsoft.FSharp.Control.FSharpAsync`1<!!0>,class Microsoft.FSharp.Core.FSharpFunc`2<!!0,class Microsoft.FSharp.Core.Unit>,class Microsoft.FSharp.Core.FSharpFunc`2<class System.Runtime.ExceptionServices.ExceptionDispatchInfo,class Microsoft.FSharp.Co
...

can't figure out async trace due to dotnet dump not working for me on this machine

[leolorenzoluis]

Could it be related to dotnet/sdk#23267?

[razzmatazz]

Could it be related to dotnet/sdk#23267?

that looks like a sdk issue to me, but this one is related to F# libraries/fsac interaction, IMHO

[leolorenzoluis]

Have you tried with .net 7 preview?

[razzmatazz]

Have you tried with .net 7 preview?

not yet, will do later today; there reports of this happening (high cpu usage) on non-arch related issue, like #975 so it coul dbe that the default settings of emacs+lsp over fsac were triggering this behaviour

[deapsquatter]

I've tried a bunch of various settings with emacs+lsp and the latest fsac and just cannot get the CPU to calm down. The CPU stays pegged very high. Disabling lsp and using Eglot works perfectly for me (although I miss some of the features like inline hints). I'm on Intel macOS.

[razzmatazz]

I think this has been fixed with the latest version; cannot replicate anymore with v0.56.2

the fix most probably was #977 by @Krzysztof-Cieslak

closing

[razzmatazz]

Oh, it seems the CPU issue is back for me on my M1 machien, so the relief was temporary/triggered by some state/project contents

[TheAngryByrd]

Since this seems like a dotnet/runtime issue I'm gonna close this.