bung87/vscode-rails

Extension causes high cpu load

PedroArSp opened this issue · 12 comments

bung87.rails-unresponsive.cpuprofile.txt

  • Issue Type: Performance
  • Extension Name: rails
  • Extension Version: 0.16.2
  • OS Version: Windows_NT x64 10.0.18363
  • VSCode version: 1.43.2

⚠️ Make sure to attach this file from your home-directory:
⚠️C:\Users\pedro\bung87.rails-unresponsive.cpuprofile.txt

Find more details here: https://github.com/microsoft/vscode/wiki/Explain-extension-causes-high-cpu-load

experiencing this on mid to large size projects all the time, very annoying. sometimes restarting vs code helps, sometimes not

Could you provide a open source project that I can test? I can't image how large it is , this problem reporting for several months, but I did not face it myself.

I do hit this issue regularly as well. VSCode becomes totally unusable, I cannot copy-paste things around, nor save a file. Typing still works (but cannot save it 🤷 ). I have a 3,7 GHz 10-Core Intel Core i9, 32 GB of Memory, and an NVME with enough free space --thus pretty sure, that my machine is not the bottleneck here.

I can't link any project atm, but I am having only one project opened in VSCode, about ~ 7-15 files at the same time. Project size is small to medium; the number of files (roughly):

  • 500 .rb
  • 150 .vue
  • 500 .js
  • 50k files in node_modules

The folder is about 3GB in size (including some large media files, which I do not have open in VSCode).
I couldn't find the cpuprofile.txt on my machine 🤷

Thanks!, that's much detail, I never used in such big project, let me see what I can do for this, maybe I'll create a refactor all code. that will take times, I've seen much reporting cpuprofile.txt that may not contains any clue to this. btw "good machine"

as 0.16.11 , I add findFiles maybe reduce the performance issue.

  • findFiles in root of document and repect gitignore previous just workspace.findFiles

I am constantly getting this issue too. Please find my profile attached.
bung87.rails-unresponsive.cpuprofile.txt

looks like it take too much time find symbol when you hover on a symbol. previous reported txt did not contains same content, maybe not same problem or vscode improve its report I guess.

{
            "id": 27,
            "callFrame": {
                "functionName": "provideHover",
                "scriptId": "902",
                "url": "file:///home/coder2000/.vscode/extensions/bung87.rails-0.17.1/dist/extension.js",
                "lineNumber": 32445,
                "columnNumber": 16
            },
            "hitCount": 0,
            "children": [
                28
            ]
        },
        {
            "id": 28,
            "callFrame": {
                "functionName": "getSymbol",
                "scriptId": "902",
                "url": "file:///home/coder2000/.vscode/extensions/bung87.rails-0.17.1/dist/extension.js",
                "lineNumber": 1441,
                "columnNumber": 18
            },
            "hitCount": 31498,
            "positionTicks": [
                {
                    "line": 1454,
                    "ticks": 31498
                }
            ]
        }

table columns on hover now use cached content will not doing file io every time, see if can reduce the problem, don's see any problem with getSymbol

I'm getting something similar on 0.17.3, not sure if it's related. This one makes my editor lock up but I think it locks up either because this problem has some weird interaction with vscode-neovim, or because it's starting a debugger in the background?

Here's my developer console with the weird "debugger attached" message.

Screen Shot 2021-07-01 at 6 26 35 PM

Here's the CPU profile it spat out:

https://gist.github.com/taylorthurlow/06db37ce5a8dd9f79174ef68b0d46460

The only solution I have for this one is to reload the window.

the first error is catched , it will return a rejected promise. the second error I may do check file exists before parse db schema. for now initial your db schema first.

the main problem is vscode's activated extensions share limited resources , to properly report performance issue I think users need deactive others extensions .

the main problem is vscode's activated extensions share limited resources , to properly report performance issue I think users need deactive others extensions .

Gotcha. Sadly for me the problem doesn't happen often enough to be able to do that without wasting a bunch of time. Thanks for taking a look, though. Do you know why the extension host would log "Debugger attached"? I'm not in any sort of debugging session.