minad / jinx

🪄 Enchanted Spell Checker
GNU General Public License v3.0
432 stars 21 forks source link

Excessive cpu and memory usage for org file with Julia Logging debug output #35

Closed ericsfraga closed 1 year ago

ericsfraga commented 1 year ago

I've been using jinx for some days now and really like it. It works very well generally. However, I've run into a strange case where jinx gets bogged down by org parsing. The file I have has several thousand lines that look like this:

┌ Debug: Placing hot node
│ node = n29
└ @ HeatExchangerNetworkDesign ~/s/research/julia/HeatExchangerNetworkDesign/src/HeatExchangerNetworkDesign.jl:1102
┌ Debug: Layout for node
│ node = n18
│ y = 6
└ @ HeatExchangerNetworkDesign 

Visiting the org file with jinx-mode enabled, Emacs basically freezes for some time with 100% CPU usage. The profile output for cpu usage shows:

       47871 96% - jinx--check-pending
       47869 96% - jinx--check-region
       47861 96% - jinx--flyspell-ignored-p
       47861 96% - org-mode-flyspell-verify
       47837 96% - org--flyspell-object-check-p
       47837 96% - org-element-context
       46973 94% - org-element--object-lex
       46022 92% - org-element-code-parser
         340 0% - org-element--parse-generic-emphasis
         328 0% + rx-to-string
         859 1% + org-element-italic-parser
[...]

with the memory usage

    326,775,960 96% - timer-event-handler
    326,674,976 96% - apply
    325,996,129 96% - jinx--timer-handler
    325,678,345 95% - jinx--check-pending
    325,657,281 95% - jinx--check-region
    325,636,601 95% - jinx--flyspell-ignored-p
    325,636,601 95% - org-mode-flyspell-verify
    325,072,246 95% - org--flyspell-object-check-p
    325,072,246 95% - org-element-context
    325,026,076 95% - org-element--object-lex
    215,616,248 63% - org-element-italic-parser
    211,670,968 62% - org-element--parse-generic-emphasis
    211,670,968 62% - rx-to-string
    186,054,064 54% - rx--translate
    186,054,064 54% - rx--translate-form
    181,758,312 53% - rx--translate-seq
    155,393,544 45% - rx--translate
    155,393,544 45% - rx--translate-form
    107,261,576 31% - rx--translate-or
    100,408,048 29% - mapcan
     99,194,744 29% + #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_2>
      2,524,984 0% rx--translate
     45,311,856 13% + rx--translate-not
      8,427,544 2% + rx--sequence
     10,559,024 3% + rx--atomic-regexp
     83,089,056 24% + org-element-code-parser
      4,458,332 1% + org-element-verbatim-parser
        342,616 0% + org-log-into-drawer

I will post a link to this issue on the org mailing list as well. Turning off jinx-mode restores normal behaviour in the org buffer.

minad commented 1 year ago

Thanks. This is a known issue - the Org-mode flyspell predicate can be slow under certain circumstances. My recommendation is that you remove jinx--flyspell-ignored-p from the jinx--predicates list. There is probably nothing we can do about this issue in Jinx. Maybe the Org maintainers could try to speed up the flyspell-mode-predicate somehow. I would appreciate if you report the issue on the Org mailing list.

ericsfraga commented 1 year ago

Okay, thank you. I didn't see this in the closed issues but maybe I didn't look close enough. I have reported this on the org mailing list.

minad commented 1 year ago

Nothing wrong with reporting this! I meant that I have observed myself that the Org predicate is the most expensive step during checking. Another alternative which could work for you is to add a custom predicate early in the list such that the problematic block are skipped immediately before checking the words and before calling the flyspell predicate. But that's all we can do, either remove the flyspell predicate completely or prevent it from running by guarding it with an additional predicate.

minad commented 1 year ago

See the mailing list thread: https://lists.gnu.org/archive/html/emacs-orgmode/2023-04/msg00092.html