Apex extension causing Java process high CPU (100%) impact

[cvinning]

Summary

Java process originating from apex extension /.vscode/extensions/salesforce.salesforcedx-vscode-apex-45.1.0/out/apex-jorje-lsp.jar -Ddebug.internal.errors=true -Ddebug.semantic.errors=false apex.jorje.lsp.ApexLanguageServerLauncher
is causing high CPU load and energy impact (and lovely fan noise) in macbook pro.

Additional information

Java process was dumped and uploaded to https://fastthread.io:443/my-thread-report.jsp?p=c2hhcmVkLzIwMTkvMDIvMTIvLS1kdW1wLmxvZy0tMjItMzctMjE=

Many threads are stuck in a BLOCKED state.

macOS Mojave 10.14.3
MacBook Pro (15-inch, 2018)

Steps taken in attempt to alleviate this issue:
Completely removed all Java/Oracle runtime and resources (via sudo -rm) in /Users/Library/, /System/, /Library/ and reinstalled JDK 8 (_131, _201, _202 builds). Completely removed all Visual Studio Code application data, cache, and extension directories as well as extension-dependent resources (including apex.db) from project folder. Repeated previous steps and opened a new project (same config). Restarted the machine at appropriate intervals during this process and verified expected uninstallation results.

By looking at the raw stack trace, impl.index.ApexIndexer.deleteTypeInfo appears to be hanging. I'm not sure if the Database object calls are looking to perform I/O on apex.db and there happens to be problems in that particular area. This is all speculation since that is proprietary code and I cannot debug either of those resources. On that note, it would be great if the .jar was open source!

[praksb]

@cvinning Thanks for reporting this issue and uploading the dump. Can you please share with us the size of your apex project (approximate number of classes/triggers etc.)? Did the spike in CPU usage happen at startup when you opened the Apex project or after performing a certain operation (like refactoring or addition/deletion of a class?

[ntotten]

Possible duplicate of #968

[cvinning]

@praksb total number of files matching *.cls is 781.

The spike occurs when the first key is pressed causing the Autocomplete to trigger. Opening the project is fine until the first key is typed in any apex file.

[cvinning]

update: I reinitialized my project from scratch with a fresh pull from our git repo. Upon opening the project folder and inspecting the newly created apex.db file in the new project vs the apex.db file in the existing project, the difference in size is pretty massive given that both folders contain identical source files being tracked. The apex.db file in the existing project folder is over 20 MBs, and the apex.db file in the newly created project is 14.4 MB.

The problem still persists in the new project folder, albeit much less exaggerated. For every last keystroke that triggers the autocomplete to render, CPU load skyrockets for ~20-30 seconds. It appears I/O is a major bottleneck for the apex extension, which is understandable. Maintaining real-time validation state, autocompletion, etc of large text blobs against a massive cache isn't a trivial task. But it also appears that the apex.db file is becoming corrupted over time. I hope this insight helps. For now, I am forced to disable the addon while on battery power and whenever my macbook begins to feel like a space heater. Godspeed, @praksb I believe in you!

[paul-drozd-itechart]

Having the same issue

[praksb]

@cvinning Your thread dump helped us to repro the perf issue on our end. Thank you!!!

We have made some improvements to Apex LSP performance in our latest extension update. Can you please update to the latest Apex extension (v45.3.0) and let us know if you still have any performance issues? Please open a new github issue if you still see any perf related problems.

#1092