Version 6.2.0 consumes a lot of CPU and memory resources

[intractabilis]

It's starts ok, but as soon as I start typing, it consumes 100% of one of the CPU cores and 5GB of memory, the laptop becomes very noisy.

I see the following process occupies the resources:
/usr/bin/java -Xms64m -Xmx512m -classpath /home/user/.vscode/extensions/valentjn.vscode-ltex-6.2.0/lib/ltex-ls-6.2.0/etc:/home/user/.vscode/extensions/valentjn.vscode-ltex-6.2.0/lib/ltex-ls-6.2.0/lib/ltexls-languagetool-patch-6.2.0.jar:/home/user/.vscode/extensions/valentjn.vscode-ltex-6.2.0/lib/ltex-ls-6.2.0/lib/* -Dapp.name=ltex-ls -Dapp.pid=21075 -Dapp.repo=/home/user/.vscode/extensions/valentjn.vscode-ltex-6.2.0/lib/ltex-ls-6.2.0/lib -Dapp.home=/home/user/.vscode/extensions/valentjn.vscode-ltex-6.2.0/lib/ltex-ls-6.2.0 -Dbasedir=/home/user/.vscode/extensions/valentjn.vscode-ltex-6.2.0/lib/ltex-ls-6.2.0 LtexLanguageServerLauncher

I set "ltex.trace.server": "verbose", the language server output generates the following text every second over and over:

авг. 15, 2020 1:14:49 AM org.bsplines.ltexls.DocumentChecker checkAnnotatedTextFragment
INFO: Checking the following text in language 'en-US' via LanguageTool: 'some text'... (truncated to 100 characters)
авг. 15, 2020 1:14:49 AM org.bsplines.ltexls.DocumentChecker checkAnnotatedTextFragment
INFO: Obtained 1 rule match
авг. 15, 2020 1:14:49 AM org.bsplines.ltexls.DocumentChecker checkAnnotatedTextFragment
INFO: Checking the following text in language 'en-US' via LanguageTool: '\n\n\n\n[variant = american]english\n\n\n\nskins, minted, listings \n\nEB Garamond[ Numbers = Proportional, Up'... (truncated to 100 characters)
авг. 15, 2020 1:14:51 AM org.bsplines.ltexls.DocumentChecker checkAnnotatedTextFragment
INFO: Obtained 323 rule matches

The language client output window is flooded with

Received notification 'telemetry/event'.
...
Received notification 'textDocument/publishDiagnostics'.

They come with 1 second interval as well. Each 'textDocument/publishDiagnostics' occupies 5000 lines of JSON.

[valentjn]

Please fill out all the info in the bug report template. Without a minimal example document and your configuration (i.e., settings starting with ltex.), I won't be able to reproduce this.

[intractabilis]

I can't send you my private documents. Though I can debug your code, if you give me a direction.

[valentjn]

A minimal example document is not the original document for which the bug occurs, but a small example document (for which the bug still occurs, of course)--usually just a few lines with some dummy text. As it says in the docs: try to delete some parts of your document and see if the bug still occurs. In addition, try to delete some parts of your configuration and see if the bug still occurs. Post both minimized document and config here.

Regarding debugging, the issue could be anywhere right now in either vscode-ltex or ltex-ls or both (see https://valentjn.github.io/vscode-ltex/docs/contributing-code-issues.html#how-to-contribute-code). If I knew where to look, I'd do it myself, but without a minimal example document and the LT_EX configuration, I won't be able to help. This info is pretty much essential.

[intractabilis]

It's the end of the term and I don't have time to experiment with documents. Maybe later.

Can I just somehow connect with a debugger to the jvm and get information which class generates the CPU cycles? Or profile it? Java is not exactly my domain.

[valentjn]

People in #29 used VisualVM to profile a similar issue. However, it seems that as in #29, your problem is that the document is checked over and over again. Therefore, I assume a profiler won't be of much use--you'll just be seeing all the time wasted in LanguageTool. To find out why the checking happens, I think you'll need to debug.

Although debugging Java bytecode is possible (I don't know anything about it though), debugging the source will resolve the issue faster. Without the additional info, I'm not sure if anyone here can help you.

[intractabilis]

I read #29. It seems like the problem could be the same as described there: a whole recheck of the document is triggered on every keystroke. Then the rechecks stack up. I can see it in JSON logs. The client sends

[Trace - 19:12:31] Sending request 'textDocument/codeAction - (80)'.
Params: {
    "textDocument": {
        "uri": "file:///home/user/document.tex"
    },
    "range": {
        "start": {
            "line": 533,
            "character": 12
        },
        "end": {
            "line": 533,
            "character": 12
        }
    },

on every keystroke with character value incrementing every time. The server replies every time with 4500 lines of JSON inside 'textDocument/publishDiagnostics'. These exchanges occupy the full of CPU time.

[valentjn]

Yes. That's what I suspected, but that doesn't really help me. We need the requested info.

The resolution of #29 was also delayed for a long time, because that info was missing.

If minimal example document and minimal settings are not provided, this will be closed as stale after 7 days per the contribution guidelines.

[intractabilis]

Yes. That's what I suspected, but that doesn't really help me. We need the requested info.

I merely shared my observation.

this will be closed as stale after 7 days

Oh, wow. So the attitude is you are making me a favor? Closing it right now, then. I was trying to help. Gosh, I was going even to debug for these guys.