High CPU usage caused by java platform se binary

[zwwi]

Describe the bug
This is not really a bug. But when I enabled the LTeX extension, there was a high cpu usage caused by java platform se binary.
I like this extension. Thank you for developing this, but the fan noise is a bit annoying...

Steps to reproduce
Steps to reproduce the behavior:
Use vs code + latex workshop, enable ltex, after a few minutes, there would be a high cpu usage.

Version information
List here the version information of the relevant software.

• Operating system: Windows 10
• VS Code: 1.43.0
• LTeX: 4.7.10
• LTeX language extensions: English (en-us)
• Java: x.xx (usually from java -version)
  java version "1.8.0_241"

[valentjn]

@zwwi When does the high CPU usage occur? When you're opening a new document? When you type something in an open document? Or without doing anything?

It would help a lot if you could attach an example document for which this occurs, or any additional information that helps me reproduce the issue. LT is known to be CPU-demanding when checking, but it shouldn't do anything when not checking.

[zwwi]

@valentjn Sorry for the lack of enough information. I checked more carefully, and find this happens when the cursor is hovering over the identified issue and LTeX is checking for quick fixes. Each check normally takes a few second. So you mean this is known, I will then close this issue. Thank you for your quick response.

[konstantin-schekotihin]

I still have a problem with LTeX while writing a bit lengthy journal article. Even when I do nothing the checker is heavily loaded and it might take 4 to 5 minutes until the process stops using the CPU. I do not experience this behavior while modifying the same paper in TexStudio, which also uses LanguageTool 4.8 server as a spellchecker.

VisualVM Profiler shows that the process is mostly busy with checking, although I cannot detect what it does exactly. I made a screenshot of the profiler sampling the CPU time during one of such lengthy background checks.

[valentjn]

@konstantin-schekotihin Thanks for the profiling. Everything inside org.languagetool.JLanguageTool is LanguageTool (LT) and out of scope for LT_EX, whose code is in org.bsplines.languagetool_languageserver. Remaining possibilities for differences to TeXstudio that I see right now are the number of checking calls of LT made by LT_EX, the configuration of LT (language, etc.), and the configuration of Java (heap size, etc.).

To help narrowing it down a little, could you post as much useful info from https://github.com/valentjn/vscode-ltex/blob/master/.github/ISSUE_TEMPLATE/bug-report.md as possible, especially the LT_EX configuration in your settings.json?

[konstantin-schekotihin]

Hi Julian,

Thanks for the fast reply and your work!
Unfortunately, I could not reproduce the problem over the last days. I'll try to "catch" it and provide you with the required info.

Best,
Konstantin

[deividrvale]

I am also having the exact same issue while hovering over a possible problem. The CPU usage go high enough for the laptop fan to get noisy.

These are the moments that it goes much higher. When I am typing the CPU usage is also high and updates on the issues now takes some time. After leaving the document quiet for a while the cpu level goes down again.
I had to close vs-code and kill the java process a bunch of times now, since as times goes by it gets even harder to get the fixing recommendation and updates on the file.

My environment is:

Operating System: Kubuntu 19.10
KDE Plasma Version: 5.18.3
KDE Frameworks Version: 5.67.0
Qt Version: 5.12.4
Kernel Version: 5.3.0-46-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz
Memory: 15,6 GiB of RAM
openjdk version "11.0.6" 2020-01-14
OpenJDK Runtime Environment (build 11.0.6+10-post-Ubuntu-1ubuntu119.10.1)
OpenJDK 64-Bit Server VM (build 11.0.6+10-post-Ubuntu-1ubuntu119.10.1, mixed mode, sharing)

LTex Version: 4.9.0,
LTex English support version: 4.9.0,
Visual Studio Code version: 1.44.1 (the standard Microsoft build).

I didn't make any changes on the extension configuration apart from setting the language to "en-US" like it is recommended.

If more information is needed, please let me know.

[valentjn]

@deividrvale As it's working for me¹, precise steps to reproduce it would help a lot. On a vanilla VS Code installation, what do you have to do in order for the issue to appear? This should include all the steps, including extensions to install, text to type/documents to open, where to hover, etc.

¹ I open a long document, wait one minute or so, then the LT diagnostics appear; hovering diagnostics then take 0.5s for the Quick Fix... link to appear in the popup.

[deividrvale]

@valentjn I've tested the extension on others documents and projects of mine and it worked wonderfully. My visual studio is now the vanilla with only extensions being Latex-workshop, vscode-icons, LTex, and LTex English.

I noticed something new though, this problem seems to happens only when I ignore some rule using the option Ignore rule in this sentence.

The ignored rules goes to the file "settings.json" inside the workspace folder ".vscode". When I delete this folder close the file tab and open it again the "Checking for quick fixes..." is almost instantaneous again.

As I ignore more rules it takes longer for the "Checking for quick fixes..." add the recommended action/quick fixes. With the same problems to the CPU usage.

When you have enough rules in this file it takes a real-long time to analyze the file.

For now on I am ignoring rules by just not doing anything instead of adding them to the ignored list.

Please, let me know if this also happens with you, and I must say: thank you for all your work on this extension.

Edit:
Adding rules to the dictionary didn't had any affect on performance for me.

[Markyparky56]

Would just like to add that I've been seeing something similar to this pretty regularly, I had one "ignore rule in this sentence" entry in my settings.json. I just removed it and restarted VSCode. CPU usage has dropped to basically 0% (before it was sitting at ~14% from just the java process) and the Quick-Fix option now appears instantly instead of after several seconds or never.

[valentjn]

Thanks people for the input. I can confirm there was indeed a bug.

For the background: LT has a cache which contains a list of the recently checked sentences (all text is split into sentences by LT). With this cache, when you edit some sentence, LT doesn't have to check all the other unchanged sentences again, which saves a lot of time.

If the setting ltex.ignoreRuleInSentence was not present or just an empty list, everything was fine. However, if at least one rule/sentence pair was present in this setting, LT_EX would clear the language cache on every edit. This means on every character stroke, a whole recheck of the document was triggered, which can take a while, depending on the length of document. The rechecks stacked up, so you had to wait several minutes after your final keystroke until LT_EX had processed all of the rechecks.

[valentjn]

Fix released in 4.9.1.

[chirag127]

Thanks people for the input. I can confirm there was indeed a bug.

okay I got it what is causing high cpu , thanks for confirming the issue.