100% CPU usage on Macbook Pro in VSCode

[dmtask]

Hi,

I'm using the Ember Language Server plugin in VSCode and have noticed increased CPU usage for a few days. VSCode is using 100% CPU, which, upon closer inspection, is caused by the "Ember Language Server" plugin in VSCode. I disabled the plugin, and the CPU usage decreased immediately. Is this a known issue?

I'm using the following versions:
VSCode: 1.100.3 (Universal)
Plugin: 3.0.64

I'm using MacOS version 15.5.

[evoactivity]

Not a known issue no. I haven't seen this behaviour. I'm on the same versions (except macos, I haven't upgraded yet).

Do you see the same behaviour if you open vscode on an empty Ember project?

[dmtask]

Not a known issue no. I haven't seen this behaviour. I'm on the same versions (except macos, I haven't upgraded yet).

Do you see the same behaviour if you open vscode on an empty Ember project?

Thanks for your reply. I'll test it with an empty Ember project and get back to you.

[dmtask]

I'm having the same Problem with an empty ember project. However, I'm also using ember version 3.28. Could this be a problem?

[evoactivity]

@lifeart Do you know how this could be further debugged, is there someway @dmtask can profile the language server to see what task is using the CPU?

[lifeart]

Most CPU intensive task we could have is - template tokens collection - https://github.com/ember-tooling/ember-language-server/blob/master/src/utils/template-tokens-collector.ts

But it's runs in a queue and should be non-blocking.
Could be disabled by this config property: https://github.com/ember-tooling/vscode-ember/blob/master/package.json#L74C10-L74C36
els.local.collectTemplateTokens -> false

[lifeart]

Another possible root cause - is improved node detection in inverse blocks:
Change in this repo: c34bff1
Change itself: ember-tooling/ember-language-server#427

Seems we need to figure out reproduction case where this logic causing infinite loop.

Case to figure out:
node.type = "block" in this iterator: https://github.com/ember-tooling/ember-language-server/blob/master/src/glimmer-utils.ts#L338

{{#if foo}}
we
{{else if bar}}
ee
{{/if}}

Case may be like: block -> blockStatement -> block -> blockStatement

Can't catch error((, tests here: ember-tooling/ember-language-server#429

[dmtask]

@lifeart Do you know how this could be further debugged, is there someway @dmtask can profile the language server to see what task is using the CPU?

@evoactivity I have no idea how this works.
@lifeart I will try deactivate this config els.local.collectTemplateTokens and test this.

Thanks for your ideas.

[dmtask]

Disabling the config (els.local.collectTemplateTokens) solved the problem. So far, the plugin is working perfectly.

[MrChocolatine]

To this day, this is still a problem, so not sure why this issue has been closed as "completed".

Personally, disabling els.local.collectTemplateTokens doesn't change anything, I have to disable the extension entirely to have my VSCode responding again.

Besides, disabling a setting is not a long-term solution, something should be fixed/improved in the extension.

[lifeart]

Hi @MrChocolatine! Thank you for bringing it up!
At the moment main problem with this issue - is reproduction.
I unable to reproduce it (and create proper fix) this is PR with experiments (trying to 'loop' code - ember-tooling/ember-language-server#429), but all works fine.

If you have time to create minimal reproduction or debug existing issues a-bit, it will be great!

[MrChocolatine]

@lifeart , I will try my best but can't promise anything as I am encountering this issue when working on my professional laptop, in our large monorepo. Despite only working with VSCode Workspaces so my extensions don't have to crawl the entire monorepo.

[MrChocolatine]

I confirm it's not easy for me to track and/or the issue from my professional laptop because:

• even taking a photo of my screen would likely be a gross misconduct
• due to privacy/security concerns, I won't log in to my personal Github account with my professional laptop

In addition to the original issue, not sure it's entirely related (who knows) but I closed my VSCode something like 10-15 being listed while taking 1.77 GB of RAM.

I can't say for sure the extension is the culprit but it's the only thing I see, still listed as an active process that is related to VSCode. (I also have a few node processes still running despite the fact only the Finder and Obsidian are open).

[lifeart]

@MrChocolatine thank you for investigation! To be able to debug and comply company rules, I would suggest to build extension from scratch and run it in debug mode. It allow you to inspect internals and figure out CPU intensive work.