Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ericsfraga opened this issue Apr 6, 2023 · 4 comments

Comments

@ericsfraga
Copy link

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
Copy link
Owner

minad commented Apr 6, 2023

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.

@minad minad closed this as completed Apr 6, 2023
@ericsfraga
Copy link
Author

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
Copy link
Owner

minad commented Apr 6, 2023

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 added a commit that referenced this issue Apr 6, 2023
The flyspell-mode-predicate is not guaranteed to be sufficiently fast for our
purposes. In particular for Org the predicate is O(buffer-size). For now we
purely rely faces. We could add more mode-specific predicates if that turns out
to be necessary.
@minad
Copy link
Owner

minad commented Apr 6, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants