Omnisharp-roslyn: Intellisense CPU usage high

[jrieken]

_From @h0rdak on December 16, 2015 8:54_

Whenever I use intellisense in my C# projects, the CPU usage spikes and makes my fans go crazy and my laptop unbearably hot to the point it's completely unusable.

This is with vs code 0.10.3 on OSX 10.10.5, on a macbook pro.

Activity monitor points to vs code -> electron helper -> mono-sgen

Installed mono is:

Mono JIT compiler version 4.2.1 (Stable 4.2.1.102/6dd2d0d Wed Dec 2 14:02:16 PST 2015)

_Copied from original issue: Microsoft/vscode#1368_

[jrieken]

@h0rdak Any details you can share with us? Project size and kind (dnx, msbuild) Could you attach the OmniSharp Log (Cmd+L L)?

[StigOlavsen]

This is with an empty Unity project, using the integration plugin.

Looking at the log, I seem to be getting an exception whenever intellisense is triggered:

System.ArgumentException: Diagnostic must have span '[128..128)'

Attached log, I get a new one of these every time intellisense is triggered.

vscodelog.txt

[jrieken]

Thanks. The errors are unhappy but shouldn't be the cause of the issue. Can you also hint to the version of mono you are using?

[StigOlavsen]

Mono JIT compiler version 4.2.1 (Stable 4.2.1.102/6dd2d0d Wed Dec 2 14:02:16 PST 2015)

Was using 4.2.0 initially, ran into this and upgraded, still the same issue.

[StigOlavsen]

I seem to have fixed the issue by installing dnvm and using it to download and install dnx-mono.1.0.0-rc1-update1

EDIT: Nope, sorry spoke too soon, still a problem.

[shochet]

Same problem here with slow intellisense and high cpu. Just started after rebooting this morning.
mono-sgen and Electron Helper both run out of control for 20 seconds whenever I trigger intellisense, or go to definition, Find all references, etc.

VSCode 0.10.5
Unity 5.1.4
Mono 4.2.0
Macbook Pro OSX 10.11.2

Driving me crazy...

[troydai]

Hi @jrieken. It has been a few months since you file this issue. Since then on dev branch, we introduced new tool-chain and update the Roslyn to 1.1.1. Can you try out the dev branch build to see if this is still a huge issue?

[fishg]

How to upgrade VSCode's roslyn?

[troydai]

@fishg you can follow the instructions in this readme: https://github.com/OmniSharp/omnisharp-roslyn/blob/dev/README.md.

[fishg]

@troydai
Looks like build.sh have some problem on OS X:

Installing dotnet from beta channel for version 1.0.0.001897
Execute install script
source: https://raw.githubusercontent.com/dotnet/cli/43ac2b45f4173b8228b44c8a9693ac7774104cbb/scripts/obtain/install.sh
version: 1.0.0.001897
channel: beta
install: /Users/fishg/data/opensource/omnisharp-roslyn/.dotnet
./build.sh: line 35: /Users/fishg/data/opensource/omnisharp-roslyn/.dotnet/cli/dotnet: No such file or directory
* Building *
./build.sh: line 44: /Users/fishg/data/opensource/omnisharp-roslyn/.dotnet/cli/dotnet: No such file or directory
./build.sh: line 45: /Users/fishg/data/opensource/omnisharp-roslyn/.dotnet/cli/dotnet: No such file or directory
./build.sh: line 46: /Users/fishg/data/opensource/omnisharp-roslyn/.build/PublishProject/PublishProject: No such file or directory

[fishg]

@troydai Sorry, it's my network problems.

[fishg]

@troydai
When Publishing, no response.How to resolve?

NuGet Config files used:
/Users/fishg/data/opensource/omnisharp-roslyn/NuGet.Config
/Users/fishg/.nuget/NuGet/NuGet.Config

Feeds used:
https://www.myget.org/F/omnisharp-roslyn-ci/api/v3/index.json
Publishing

[fishg]

Publishing blocked long time.No any result.

[troydai]

@fishg can you copy the full log? I work on OSX full time so I doubt it is platform specific. It could be some problem with you miss some tools for packaging.

[fishg]

@troydai
./build.sh
* Cleanup *
* Installing dotnet *
Installing dotnet from beta channel for version 1.0.0.001897
Execute install script
source: https://raw.githubusercontent.com/dotnet/cli/43ac2b45f4173b8228b44c8a9693ac7774104cbb/scripts/obtain/install.sh
version: 1.0.0.001897
channel: beta
install: /Users/fishg/data/opensource/omnisharp-roslyn/.dotnet
dotnet_install: Preparing to install .NET Tools from 'beta' channel to '/Users/fishg/data/opensource/omnisharp-roslyn/.dotnet'
dotnet_install: Downloading dotnet-dev-osx-x64.1.0.0.001897.tar.gz from https://dotnetcli.blob.core.windows.net/dotnet/beta/Binaries/1.0.0.001897

################################################################## 100.0%

dotnet_install: Extracting tarball
dotnet_install: Moving new CLI into install location and symlinking
dotnet_install: Cleaning dotnet-dev-osx-x64.1.0.0.001897.tar.gz
.NET Command Line Tools (1.0.0-beta-001897)

Product Information:
Version: 1.0.0-beta-001897
Commit Sha: ca74a9b177

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.11
OS Platform: Darwin
Runtime Id: osx.10.11-x64
* Building *
log : Restoring packages for /Users/fishg/data/opensource/omnisharp-roslyn/tools/PublishProject/project.json...
info : Committing restore...
log : tools/PublishProject/project.json
log : Restore completed in 1734ms.

NuGet Config files used:
/Users/fishg/data/opensource/omnisharp-roslyn/NuGet.Config
/Users/fishg/.nuget/NuGet/NuGet.Config

Feeds used:
https://www.myget.org/F/omnisharp-roslyn-ci/api/v3/index.json
Publishing

No error log found.

[fishg]

When I deleted nuget's cache, I build successed.
But a new problem is:
dnxcore50 have a excutable OmniSharp file,but not work in vscode with Unity3D project.
dnx451 have no excutable Unix file,so I add a new sh file:

#!/bin/bash
/usr/local/bin/mono /Users/fishg/data/opensource/omnisharp-roslyn/artifacts/publish/OmniSharp/osx.10.11-x64/dnx451/OmniSharp.exe "$@"

Now works.

[fishg]

Cpu usage is also too high when open project or switch to new class file.

[troydai]

@fishg can you elaborate what doesn't work with Unity under dnxcore50 OmniSharp?

[fishg]

@troydai If use dnxcore50,process start normally, but no code any intellisense.

[troydai]

@fishg can you point me to a mini repo for missing intellisense case?

[speoplesz]

This is still an issue.

[Jodacola]

I've been struggling with instances of intensely high CPU usage at odd points while coding in VSCode for over a year, now. I previously noticed some patterns related to working on classes implementing IDisposable, and again hit the issue today, to much frustration. I've managed to recreate the issue, albeit without the high CPU usage, in a simple project. Environment, steps, and findings below.

Operating environment:

• MacBook Pro 15 Mid 2015
• 16 GB RAM
• macOS Mojave 10.14.4
• VSCode 1.33.1
• Mono JIT compiler version 5.16.0.221 (2018-06/b63e5378e38 Mon Nov 19 18:08:09 EST 2018)

Steps to reproduce

1. dotnet new console -n MonoSgenCall
2. cd MonoSgenCall
3. code .
4. Add required resources via VSCode prompt
5. Add a new file to the project named SomeDisposableClass.cs with following content:

```c#
using System;

public class SomeDisposableClass : IDisposable
{
public void Dispose()
{
}
}

6. Start Activity Monitor to monitor process on CPU tab.
7. Make any compilable change to `SomeDisposableClass` and save the file and immediately note mono-sgen64 jumps up in the Activity Monitor list.
![Screen Shot 2019-04-20 at 10 07 28 AM](https://user-images.githubusercontent.com/3253637/56459059-4c4c9200-6354-11e9-9086-9a1969013dd2.png)
8. Update `SomeDisposableClass` to not implement `IDisposable`:
```c#
using System;

public class SomeDisposableClass
{
    public void Dispose()
    {
    }
}

1. Make changes to class and save, as before
2. Note that mono-sgen64 no longer jumps to the top of the list

CPU usage jumps far, far more when running this exercise (steps 5-7) in a much larger project:

This, again, only happens for me when working on classes implementing IDisposable. This has been repeatable for a very long time for me, but I didn't take the time to collect information and steps until today. I've Googled quite a bit for IDisposable-related issues in this repo, IDisposable-related issues with Sgen in Mono, and with just VSCode, to no avail. Hopefully this can help move progress on resolving this in the right direction.

Happy to provide any additional information or testing.

[atliegils]

Nice post, @Jodacola
Did you manage to find more information to resolve this issue?

[chinaq]

I've been struggling with instances of intensely high CPU usage at odd points while coding in VSCode for over a year, now. I previously noticed some patterns related to working on classes implementing IDisposable, and again hit the issue today, to much frustration. I've managed to recreate the issue, albeit without the high CPU usage, in a simple project. Environment, steps, and findings below.

Operating environment:

• MacBook Pro 15 Mid 2015
• 16 GB RAM
• macOS Mojave 10.14.4
• VSCode 1.33.1
• Mono JIT compiler version 5.16.0.221 (2018-06/b63e5378e38 Mon Nov 19 18:08:09 EST 2018)

Steps to reproduce

1. dotnet new console -n MonoSgenCall
2. cd MonoSgenCall
3. code .
4. Add required resources via VSCode prompt
5. Add a new file to the project named SomeDisposableClass.cs with following content:

using System;

public class SomeDisposableClass : IDisposable
{
    public void Dispose()
    {
    }
}

1. Start Activity Monitor to monitor process on CPU tab.
2. Make any compilable change to SomeDisposableClass and save the file and immediately note mono-sgen64 jumps up in the Activity Monitor list.
   
3. Update SomeDisposableClass to not implement IDisposable:

using System;

public class SomeDisposableClass
{
    public void Dispose()
    {
    }
}

1. Make changes to class and save, as before
2. Note that mono-sgen64 no longer jumps to the top of the list

CPU usage jumps far, far more when running this exercise (steps 5-7) in a much larger project:

This, again, only happens for me when working on classes implementing IDisposable. This has been repeatable for a very long time for me, but I didn't take the time to collect information and steps until today. I've Googled quite a bit for IDisposable-related issues in this repo, IDisposable-related issues with Sgen in Mono, and with just VSCode, to no avail. Hopefully this can help move progress on resolving this in the right direction.

Happy to provide any additional information or testing.

This is still an issue that 3 years passed.

[SirIntruder]

Unfortunately this seems to behave badly in both Visual Studio and Visual Studio Code. I hoped it was just an omnisharp issue, but looks like it is somewhere in Roslyn repo.

There is a slight difference tough - taking a random sample in omnisharp repo (MonoScriptGenerationProcess.Disposable()), omnisharp/vscode displays 32 references, and Visual Studio displays 23 references.

Both VS and VSCode crank up to the ~100% cpu usages when this gets recalculated, with a caveat that VS seems smarter about not recalculating this anytime something gets changed in that file.

I have no idea if listing every call to Disposable() everywhere is intentional or not (32 references?), seems pretty useless IMHO...

[kruncher]

We found that tweaking the C# extension for VSCode to ignore Dispose and GetEnumerator helped a lot. The issue still occurs though, seems to be more problematic more recently with no apparent reason.

[galvesribeiro]

I have the same situation when building xUnit test projects when I have to add a fixture class that usually implements IDisposable :

At:

Using:

So... It is almost a 4yrs old issue... Is there a plan to attack this bug?

[Ursanon]

Workaroud:

Try setting:
"csharp.referencesCodeLens.enabled": false

It will disable reference counting for IDisposable interface and hide x references info, but un-lag your computer.

[yakeer]

Also experiencing this bug, MacOS Catalina - Latest VSCode.
I disabled the CodeLens references - it makes it a little bit better - but the CodeLens feature is really useful!
Hope you'll finally fix it.

Thanks.

[reckhou]

Boom, same issue here! But I'm using Windows version of VSCode & OmniSharp, the latest version.

Tried to turn off CodeLens and it fixes the issue. But hopefully that could be fixed somehow.

[galvesribeiro]

Yeah... sad to see we're entering the 5th year without a solution for that... C# is the major reason why people goes VSCode but it seem like there is not much attention to it... Sorry but disable CodeLenses is not a viable workaround... It works for other non-mainstream languages so there is no reason why it shouldn't work for the main one...

[mvalero]

Am observing exactly the same issue since several years while using omnisharp in VSCode, in Windows 10 and with several .net Core 2.1 Projects.

I already mentioned this issue in https://github.com/OmniSharp/omnisharp-vscode/issues/3079 as I thought it could be related to the omnisharp implementation in vscode, but it seems to be rather a general omnisharp roslyn problem.

As stated in the omnisharp vscode ticket the problem is really easily reproducible when editing a class that implements IDisposable with the CPU going directly to 100% utilisation. At the moment IDisposable is commented out or removed from the class the CPU usage goes quickly back to normal.

[lynzrand]

Same issue here, Omnisharp eating up 7% CPU when idle after opening a ASP.NET Core project. I'm working on 3 different-sized projects here, and Omnisharp is consuming the same CPU share when idle regardless of project size.