Performance issues: CPU and RAM usage

[faustinoaq]

Hi again @adamvoss !

Thank you a lot for this extension. Now warnings are showing as expected 👍

This issue is because java use too many computer resources, 😅

Maybe, this extension can use a portion of textDocument to check and limit the amount of warnings to show.

By example, it could analyze just the words or paragraph around current cursor, (vscode.Range) avoiding to recheck the whole document at every change.

The following image is a screen capture of java process using a lot of CPU and 800 mb in a markdown document with 140 lines. Also, the document reach the limit of warning (251) and as result it send an error.

And finally another screen capture with language tool disabled, the resource usage fall down:

I don't know How VSCode checks CSS and TypeScript errors without be resource intensive but it could be very useful for this extension.

Reference about native spellchecker in VSCode: microsoft/vscode#20266

[adamvoss]

I'll take a look and see what is possible. Unless I find something obvious that I did wrong, this will probably take longer than the last issue. Is there any way I could get a copy of the file you used in your screen shots? That would make it easier to compare and track improvements.

[faustinoaq]

Thank you for this great extension!

[faustinoaq]

BTW, to disable this extension more quickly i do this: "languageTool.language": "", in settings.json

Also, RAM usage is high but it doesn't matter too much. In other hand CPU % is important, but it only happens when a medium size text is being edited. For small text and when text is not changing languagetool isn't resource intensive.

[adamvoss]

Thanks for the file! The most I have learned thus far is that Java is greedy. Attaching a profiler and forcing performing garbage collection when the checking idle, I find it may only be using ~25 MB, but at the system level it holds on to the 1.2 GB that it peaked at while processing. I'll have to investigate how much of this is resulting from inefficient use of the Language Server protocol versus what is inherit in LanguageTool's processing to see what can be done.

Regarding CPU usage, your Markdown file does not utilize any Markdown syntax. You could try setting it to plaintext and see if that helps you at all. More processing is done on Markdown than plaintext, so, in theory, there should be less CPU usage with plaintext. Non-scientific testing on my machine showed it wasn't much difference, but your system is a bit more constrained than mine and this may give you some relief until I find a better solution. If this helps, I would consider adding a configuration flag to change the default processing behavior.

[faustinoaq]

Yes, a configuration flag would be great!. Maybe, also a configuration for filetype, something like `languagetool.filetype: [ "markdown", "plaintext"]` explaining that only these filetype are supported and allowing to disable then by removing from array in settings.json . BTW, I want to thank you, excellent support 👍

…

On Thu, Jun 15, 2017 at 11:34 AM, Adam Voss ***@***.***> wrote: Thanks for the file! The most I have learned thus far is that Java is greedy. Attaching a profiler and forcing performing garbage collection when the checking idle, I find it may only be using ~25 MB, but at the system level it holds on to the 1.2 GB that it peaked at while processing. I'll have to investigate how much of this is resulting from inefficient use of the Language Server protocol versus what is inherit in LanguageTool's processing to see what can be done. Regarding CPU usage, your Markdown file does not utilize any Markdown syntax. You could try setting it to plaintext and see if that helps you at all. More processing is done on Markdown than plaintext, so, in theory, there should be less CPU usage with plaintext. Non-scientific testing on my machine showed it wasn't much difference, but your system is a bit more constrained than mine and this may give you some relief until I find a better solution. If this helps, I would consider adding a configuration flag to change the default processing behavior. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC7Nx9sE_0U8Q0mRZUENsLsN5VN8JsACks5sEV0vgaJpZM4N6xm6> .

[adamvoss]

Yes, a configuration flag would be great!

Did changing the language really make a difference? I am hesitant at this point to add configuration settings (that would then need to be supported) without having a definite need.

[faustinoaq]

Ok, Don't worry about adding more configuration, the extension is working well.

Now aims to improve performance 😅

[adamvoss]

To really optimize this well, it looks like a custom harness will need to be built. Between the server component spending most of its time listening, and triggering execution being a human driven process via a GUI, I am not finding it easy to get useful profiling results.

Taking a little less informed approach, I do see that when typing it can end up checking multiple times per second. CPU usage could be reduced with minimal delay to checking by adding a little bit of a buffer.

[faustinoaq]

Currently, I think this issue is fixed. adamvoss, Thanks for you support 😄

[denysvitali]

I don't think this issue is fixed...

WTF. 10GB + 2GB of VRAM/RAM.

[faustinoaq]

@denysvitali Wow, I never reached that huge amount of memory, The max RAM this extension did take in my pc was around 1GB

10 GB is insane 😅

[adamvoss]

@denysvitali Yes, this still would be an issue. I looked at it before enough to not see that the code was doing anything obviously bad with respect to memory and that when I would use a profiler to force garbage collection, the memory usage reduced to a sane level, suggesting against the high usage being a memory leak. One thing I did observe is that there is essential no "throttle" on the checking, so [I believe] it will run multiple requests even when the user is continuing to type triggering even more requests. Each of these request allocate memory for processing that will not be freed until garbage collected. If we are not letting so many request process memory growth could be slowed (in theory).

As alluded to in #4 (comment) a testing harness would need to be built for this to get a better idea of what the actual issue is and whether changes have any effect.

@faustinoaq It may have something to do with their machine having 32GB of physical RAM creating less memory pressure meaning less frequent garbage collection.

[unknownterritory]

Just confirming that this is still a concern on this otherwise vital extension. I experience the same type of consumption than denysvitali reported. Thanks!

[kmort89]

I'm also witnessing virtual memory usage in ranks of ~12GB.

It seems that the invocation of format:

java -classpath /home/USER/.vscode/extensions/adamvoss.vscode-languagetool-3.8.0/lib/languagetool-languageserver/build/install/languagetool-languageserver/lib/*:/home/USER/.vscode/extensions/adamvoss.vscode-languagetool-en-3.8.0/lib/*:/home/USER/.vscode/extensions/adamvoss.vscode-languagetool-sv-3.8.0/lib/* App 44193

Have you considered adding -Xmx flag? For example -Xmx512M by default but allow it to be configured in the plugin settings?

[davidlday]

Please see #25.

[ogmios-voice]

Based on the installed extension (extensions\adamvoss.vscode-languagetool-3.8.0\lib\languagetool-languageserver\build\install\languagetool-languageserver\bin\languagetool-languageserver.*) set the following environment variable e.g. for Java 8 to:

LANGUAGETOOL_LANGUAGESERVER_OPTS = -noverify -Xms256M -Xmx256M -XX:MaxMetaspaceSize=256m -XX:+UseG1GC -XX:+UseStringDeduplication
(The exact limits will require further testing/profiling.)

This information should be included in the readme file too.

Also upon exiting Visual Studio Code, the java subprocess is not killed immediately (only after ~1 min).