Large pop-up delay for "Show Fixes" on Linux

[bugabinga]

• Extension Name: spellright
• Extension Version: 2.1.0
• OS Version: Linux x64 4.14.11-300.fc27.x86_64

• VSCode version: 1.19.1

  {
  "activationTimes": {
      "startup": true,
      "codeLoadingTime": 103,
      "activateCallTime": 39,
      "activateResolvedTime": 0,
      "activationEvent": "*"
  }
  }

After long periods of time (~3h) using vscode with the extension to author Markdown documents it gets very slow. Specifically the Auto-Suggetion (Ctrl+.) pop-up needs 20-40 seconds to show up after pressing the shortcut. The application stays responsive during that time (scrolling, editing, etc) and the pop-up then shows regardless of context (even if view switched or vscode in background). The documentation mentioned to disable a setting on Linux for performance reasons which I have already done.

[bartosz-antosik]

Hi! You mention if I get this correctly that it generally gets slow - could you please elaborate on this?

Also, the could you please tell which setting you have set? I think this was spellright.suggestionsInHints but please confirm. Also - this setting determines whether the suggestions are added to the diagnostic messages (in PROBLEMS panel).

What language do you use the library with? Are there more than one language in the document (e.g. switched with In-Document commands)?

[bugabinga]

On Sat, 2018-01-06 at 10:01 +0000, Bartosz Antosik wrote:

Hi! You mention if I get this correctly that it generally gets slow - could you please elaborate on this?

It is hard to be precise, because it seems to happen after longer sessions of using vscode. The editor is not generally becoming slow. Only the time from hitting Ctrl+. until pop-up with correction suggestion is shown is the issue.

I would like to profile this or provide more useful logs. Do you know how to do that?

Also, the could you please tell which setting you have set? I think this was spellright.suggestionsInHints but please confirm. Also - this setting determines whether the suggestions are added to the diagnostic messages (in PROBLEMS panel).

Yes, this setting is the one.

What language do you use the library with? Are there more than one language in the document (e.g. switched with In-Document commands)?

Language is set to "English - United States". No additional languages have been set. However, I have added multiple dictionaries into the config folder $HOME/.config/Code/Dictionaries/:

[oliver@thnkpd ~]$ exa -l .config/Code/Dictionaries/
.rw-r--r--@  18k oliver 26 Jul  2017 de_AT.aff
.rw-r--r--@ 1,1M oliver 26 Jul  2017 de_AT.dic
lrwxrwxrwx@    9 oliver 26 Jul  2017 de_BE.aff -> de_DE.aff
lrwxrwxrwx@    9 oliver 26 Jul  2017 de_BE.dic -> de_DE.dic
.rw-r--r--@  18k oliver 26 Jul  2017 de_CH.aff
.rw-r--r--@ 1,1M oliver 26 Jul  2017 de_CH.dic
.rw-r--r--@  18k oliver 26 Jul  2017 de_DE.aff
.rw-r--r--@ 1,1M oliver 26 Jul  2017 de_DE.dic
lrwxrwxrwx@    9 oliver 26 Jul  2017 de_LI.aff -> de_CH.aff
lrwxrwxrwx@    9 oliver 26 Jul  2017 de_LI.dic -> de_CH.dic
lrwxrwxrwx@    9 oliver 26 Jul  2017 de_LU.aff -> de_DE.aff
lrwxrwxrwx@    9 oliver 26 Jul  2017 de_LU.dic -> de_DE.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_AG.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_AG.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_AU.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_AU.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_BS.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_BS.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_BW.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_BW.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_BZ.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_BZ.dic -> en_GB.dic
.rw-r--r--@ 3,1k oliver 25 Sep  2017 en_CA.aff
.rw-r--r--@ 541k oliver 25 Sep  2017 en_CA.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_DK.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_DK.dic -> en_GB.dic
.rw-r--r--@  27k oliver 25 Sep  2017 en_GB.aff
.rw-r--r--@ 527k oliver 25 Sep  2017 en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_GH.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_GH.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_HK.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_HK.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_IE.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_IE.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_IN.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_IN.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_JM.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_JM.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_MW.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_MW.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_NA.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_NA.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_NG.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_NG.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_NZ.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_NZ.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_PH.aff -> en_US.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_PH.dic -> en_US.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_SG.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_SG.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_TT.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_TT.dic -> en_GB.dic
.rw-r--r--@ 3,1k oliver 25 Sep  2017 en_US.aff
.rw-r--r--@ 539k oliver 25 Sep  2017 en_US.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_ZA.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_ZA.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_ZM.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_ZM.dic -> en_GB.dic
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_ZW.aff -> en_GB.aff
lrwxrwxrwx@    9 oliver 25 Sep  2017 en_ZW.dic -> en_GB.dic
.rw-rw-r--@ 245k oliver 20 Jul  2016 pl_PL.aff
.rw-rw-r--@ 4,4M oliver 20 Jul  2016 pl_PL.dic
[oliver@thnkpd ~]$ rg SET .config/Code/Dictionaries/en_US.aff
1:SET ISO8859-1

As you can see, one possible issue is that my dictionaries are not UTF-

8. I have only noticed this now. These files are sym-linked from the system installation of hunspell on Fedora 27 under /usr/share/myspell/.

   lrwxrwxrwx@ 18 oliver 10 Dez 2017 Dictionaries -> /usr/share/myspell

This may be another possible issue, the files are not linked individually, but the whole directory is.

Notice also, that I changed the owner of the dicts, because I thought that this was necessary to add custom values to the "User dictionary". I think this assumption was wrong.

As a side note: On my system, when using hunspell on the command line, one can add custom words via (I)nsert. Those words get saved into $HOME/.hunspell_{{dictionary_name}}. E.g. $HOME/.hunspell_en_US.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread. -- Oliver Jan Krylow oliver@bugabinga.net

[bartosz-antosik]

Thanks for detailed explanations. At first I do not see anything that could be wrong with the configuration apart that definitely dictionaries should be UTF-8. Sadly it's not easy to change for the moment as has been examined in #50.

I will first refer to your will to provide some log/trace. I have prepared a version with some small additional debug information printed. Please download:

https://drive.google.com/file/d/1IrqUZQxGMI3y1InrZTnyl3go0v7D9LYH/view?usp=sharing

Then install it manually from VSIX file.

Then once you notice slowness please show Console of Developer Tools (Help -> Toggle Developer Tools) and there should appear an information for the time it takes to provide the information for the menu:

P.S. I have found a unnoticed problem around the procedure which provides data for the menu called with Ctrl+., This should have nothing to do with the long time it takes to prepare it. It is related to a situation when two extensions provide diagnostics for the place (e.g. Markdown lint extension provides information for some piece of text which is also not spelled correctly). The problem has been corrected in the version you receive but as I have said - it should have nothing to do with the issue.

[bugabinga]

On Sat, 2018-01-06 at 05:21 -0800, Bartosz Antosik wrote:

Thanks for detailed explanations. At first I do not see anything that could be wrong with the configuration apart that definitely dictionaries should be UTF-8. Sadly it's not easy to change for the moment as has been examined in #50.

I do not understand why the dictionaries are not UTF-8 by default on Fedora, but hey... For the time being I will leave my dictionaries for testing purposes. In the long run I will probably download UTF-8 dictionaries from the URL you privide in the README.

I will first refer to your will to provide some log/trace. I have prepared a version with some small additional debug information printed. Please download:

https://drive.google.com/file/d/1IrqUZQxGMI3y1InrZTnyl3go0v7D9LYH/vie w?usp=sharing

Then install it manually from VSIX file.

Then once you notice slowness please show Console of Developer Tools (Help -> Toggle Developer Tools) and there should appear an information for the time it takes to provide the information for the menu:

Nice! Thanks for the help. Here is a screencast showing the issue:

https://box.bugabinga.net/cloud/index.php/s/8PX6SL4fMbOtTot

Obviously, you cannot see when I press Ctrl+., but you can see the log entry appearing. It appears instantly ater pressing Ctrl+.. After a delay the popup is shown.

Additionally here is a CPU profile generated with VSCode "Extension Host Profile":

https://box.bugabinga.net/cloud/index.php/s/8RF5Q9nj5KV4xzv

It can be loaded into the JavaScript Profiler in the Developer Tools.

When I use my laptop in battery mode, the issue is noticable more quickly (presumably because of power saving mode (CPU throtteling)).

P.S. I have found a unnoticed problem around the procedure which provides data for the menu called with Ctrl+., This should have nothing to do with the long time it takes to prepare it. It is related to a situation when two extensions provide diagnostics for the place (e.g. Markdown lint extension provides information for some piece of text which is also not spelled correctly). The problem has been corrected in the version you receive but as I have said - it should have nothing to do with the issue.

I have also the markdown lint extension installed (as well as the languagetool) and now that I have tested more thouroughly, I have noticed the popup delay is not exclusive to Spellright.

As such I am closing this issue, since this is likely not a bug in Spellright.

-- Oliver Jan Krylow oliver@bugabinga.net

[bartosz-antosik]

Many thanks for thorough investigation! I am far from saying "It's not me to blame!" but the truth is that once the log line pops the only routine that is engaged when VSCode asks anything from spellchecker is done. Just after printing the timing spellright returns to caller. So it seems it may be some VSCode related observation.