Extension causes high cpu load

rafiyah commented 5 years ago

Issue Type: Performance
Extension Name: solargraph
Extension Version: 0.19.6
OS Version: Windows_NT x64 10.0.16299
VSCode version: 1.33.1

:warning: Make sure to attach this file from your home-directory: :warning:C:\Users\Username\castwide.solargraph-unresponsive.cpuprofile.txt

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

castwide commented 5 years ago

Do you have the castwide.solargraph-unresponsive.cpuprofile.txt that the message asks you to attach?

rafiyah commented 5 years ago

Hi @castwide, sorry about that! The ticket was automatically created from VS Code and didn't realise I had to attach something. castwide.solargraph-unresponsive.cpuprofile.txt

castwide commented 5 years ago

Thanks, @rafiyah. I'm looking into possible solutions. So far I've confirmed that the language server seems to idle at a higher CPU load than it should, but I'm still trying to determine a root cause.

rafiyah commented 5 years ago

Sounds good. Thanks @castwide! :)

plindelauf commented 5 years ago

I'm having the exact same thing for months and it's driving me nuts. It seems to be caused by the fact that Solargraph is racing through directories that I have explicitly excluded. Here are the open files in my activity manager:

cwd
/Users/pascal/Projecten/RoR/my-project
txt
/Users/pascal/.rbenv/versions/2.4.6/bin/ruby
txt
/usr/local/Cellar/gmp/6.1.2_2/lib/libgmp.10.dylib
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/enc/encdb.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/enc/trans/transdb.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/stringio.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/etc.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/digest/sha1.bundle
txt
/usr/local/Cellar/openssl/1.0.2o_2/lib/libcrypto.1.0.0.dylib
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/digest.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/pathname.bundle
txt
/usr/local/Cellar/xz/5.2.4/lib/liblzma.5.dylib
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/gems/2.4.0/gems/jaro_winkler-1.5.2/lib/jaro_winkler/jaro_winkler_ext.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/openssl.bundle
txt
/usr/local/Cellar/openssl/1.0.2o_2/lib/libssl.1.0.0.dylib
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/io/nonblock.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/io/console.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/zlib.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/socket.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/io/wait.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/enc/windows_31j.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/gems/2.4.0/gems/json-2.2.0/lib/json/ext/parser.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/gems/2.4.0/gems/json-2.2.0/lib/json/ext/generator.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/ripper.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/cgi/escape.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/gems/2.4.0/gems/nokogiri-1.8.5/lib/nokogiri/nokogiri.bundle
txt
/Library/Preferences/Logging/.plist-cache.yQwAJgDH
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/readline.bundle
txt
/usr/local/Cellar/readline/8.0.0_1/lib/libreadline.8.0.dylib
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/psych.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/strscan.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/date_core.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/enc/utf_16le.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/enc/utf_16be.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/racc/cparse.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/enc/utf_32le.bundle
txt
/Users/pascal/.rbenv/versions/2.4.6/lib/ruby/2.4.0/x86_64-darwin18/enc/trans/utf_16_32.bundle
txt
/usr/lib/dyld
0
->0x8170db42e72c7b39
1
->0x8170db42e72c6eb9
2
->0x8170db42e72c7111
3
->0x8170db42e41c4459
4
->0x8170db42e41c2dd9
5
->0x8170db42e41c3c19
6
->0x8170db42e41c5359
7
/dev/null
8
localhost:52258
9
localhost:52258->localhost:52259
10
[ctl com.apple.netsrc id 8 unit 25]
11
->0x8170db42f7ad0cc9
12
192.168.42.102:52419->151.101.64.70:https
13
/Users/pascal/Projecten/RoR/my-project
14
/Users/pascal/Projecten/RoR/my-project/public
15
/Users/pascal/Projecten/RoR/my-project/public/system
16
/Users/pascal/Projecten/RoR/my-project/public/system/dragonfly
17
/Users/pascal/Projecten/RoR/my-project/public/system/dragonfly/test
18
/Users/pascal/Projecten/RoR/my-project/public/system/dragonfly/test/images
19
/Users/pascal/Projecten/RoR/my-project/public/system/dragonfly/test/images/655
20
/Users/pascal/Projecten/RoR/my-project/public/system/dragonfly/test/images/655/2017
21
/Users/pascal/Projecten/RoR/my-project/public/system/dragonfly/test/images/655/2017/12
22
/Users/pascal/Projecten/RoR/my-project/public/system/dragonfly/test/images/655/2017/12/14
23
/Users/pascal/Projecten/RoR/my-project/public/system/dragonfly/test/images/655/2017/12/14/16
24
/Users/pascal/Projecten/RoR/my-project/public/system/dragonfly/test/images/655/2017/12/14/16/41
25
/Users/pascal/Projecten/RoR/my-project/public/system/dragonfly/test/images/655/2017/12/14/16/41/14
26
vnode: FD unavailable
38
/dev/ptmx
41
/Applications/Visual Studio Code.app/Contents/Resources/app/node_modules.asar

Solargraph should NOT go through any of the items in the public directory. Here's my .solargraph.yml:

---
include:
- "**/*.rb"
exclude:
- db/**/*
- features/**/*
- log/**/*
- node_modules/**/*
- public/**/*
- spec/**/*
- test/**/*
- tmp/**/*
- vendor/**/*
- ".bundle/**/*"
- ".git/**/*"
- ".sass-cache/**/*"
require: []
domains: []
reporters:
- rubocop
- require_not_found
plugins: []
max_files: 5000

I also tried prefixing the directories with ./, but that did not make any difference. So it seems that Solargraph is simply ignoring this exclude directive.

castwide commented 5 years ago

The exclusion process is suboptimal. I'll work on making it more efficient.

Unfortunately, that particular issue might not be related to long-term CPU usage. After the first time the workspace gets calculated, the server should stop reading excluded directories. If that doesn't appear to be the case, please let me know.

One other thing that might help: narrowing includes is significantly more efficient than adding excludes. If you can make the include rule something like lib/**/*.rb, you should see better performance overall.

castwide commented 5 years ago

An update that improves performance is being tracked in #117.

plindelauf commented 5 years ago

The exclusion process is suboptimal. I'll work on making it more efficient.

Unfortunately, that particular issue might not be related to long-term CPU usage. After the first time the workspace gets calculated, the server should stop reading excluded directories. If that doesn't appear to be the case, please let me know.

One other thing that might help: narrowing includes is significantly more efficient than adding excludes. If you can make the include rule something like lib/**/*.rb, you should see better performance overall.

I've been running with the more specific include settings today and that seems to do the job! The Ruby process is now behaving nicely; no 98%+ CPU loads anymore.

FlowerWrong commented 5 years ago

+1 on mac 100%cpu

solargraph socket --port 0

castwide commented 5 years ago

@FlowerWrong Are you opening a large workspace (i.e., a folder with a lot of Ruby files)? Depending on the volume of code, the language server can take a while to initialize. When it's done, the message in the status bar should change from "Starting the Solargraph language server" to "Solargraph is ready."

For comparison, on my MacBook, a relatively small repo like castwide/backport takes about 4 seconds to initialize, while rails/rails takes about 150 seconds. After initialization is complete, the solargraph process idles at < 1%.

If any errors occurred, you might be able to get more information from the developer console (Help -> Toggle Developer Tools).

castwide commented 5 years ago

Gem version 0.33.0 includes updates that should help with high CPU loads.

Client/server communication is more efficient. The server no longer needs to queue outgoing messages and poll the buffer.
A bug that would cause type inference to enter an infinite loop is fixed.

If you still have problems, there's a new scan command you can use to check if Solargraph is having a problem indexing your workspace. From the command line, cd to the workspace root and run solargraph scan -v. The scan will index the workspace and analyze the resulting map. It might take a few minutes depending on the size of your workspace.

There are two results that can indicate a bug in Solargraph:

The scan throws an exception. The output should tell you the location in the workspace that caused the error.
The scan freezes on a pin. Each pin's probe should only take a fraction of a second. If it takes any longer, the probe has probably entered an infinite loop.

FlowerWrong commented 5 years ago

@castwide My projects is not very large, just twenty models.

solargraph scan -v

Scanned /Users/yang/dev/astarup/next (53381 pins) in 36.21303199999966 seconds.

I do not know how to let it reappear. But it happened sometimes.

castwide commented 4 years ago

The latest version of the Solargraph gem (0.39.11) includes significant improvements to CPU and memory usage. If this problem persists, please feel free to comment or open a new issue.

castwide / vscode-solargraph

Extension causes high cpu load #116