I observe intermittent sluggish behavior when using Emacs’ julia-mode in two different Windows 10 computers and Emacs 26.3: an arrow key move takes sometimes between 1 and 5 seconds. Non julia-modes are instead working fine. Has anybody experienced the same?
Could you try using the emacs profiler to see where time is spent? I have some suspicions of what the issue might be, but data is better.
This is what M-x profiler-report gives:
- linum-update-current 115,987,976 58%
- linum-update 115,982,696 58%
- mapc 115,978,472 58%
- linum-update-window 115,907,744 58%
- window-end 2,644,090 1%
- jit-lock-function 43,831 0%
- jit-lock-fontify-now 43,482 0%
- jit-lock--run-functions 42,426 0%
- run-hook-wrapped 42,426 0%
+ #<compiled 0x22d9df1> 42,426 0%
linum--face-width 324,096 0%
count-lines 31,178 0%
line-number-at-pos 6,336 0%
* 888 0%
get-buffer-window-list 4,224 0%
- command-execute 67,205,914 34%
- call-interactively 67,201,690 34%
- funcall-interactively 49,753,158 25%
- next-line 37,497,102 18%
- line-move 37,484,430 18%
- line-move-partial 35,857,490 18%
+ window-screen-lines 92,920 0%
+ default-line-height 76,008 0%
+ window-inside-pixel-edges 12,672 0%
pos-visible-in-window-p 11,135 0%
+ line-move-visual 1,217,060 0%
+ default-line-height 77,080 0%
+ window-inside-pixel-edges 17,952 0%
+ called-interactively-p 7,392 0%
+ execute-extended-command 9,456,080 4%
+ previous-line 2,452,252 1%
+ profiler-report-toggle-entry 143,184 0%
right-char 116,720 0%
+ scroll-up-command 50,116 0%
left-char 37,704 0%
+ byte-code 17,448,532 8%
+ redisplay_internal (C function) 14,310,167 7%
+ timer-event-handler 32,736 0%
+ ... 10,316 0%
+ undo-auto--add-boundary 5,280 0%
+ global-font-lock-mode-check-buffers 1,056 0%
+ blink-cursor-end 1,056 0%
I don’t see anything in that trace specific to julia-mode. Did you experience the slowdown while taking it? You could try elp-instrument-package instead.
I do see that some cpu time is taken by linum-mode which is known to cause slowdowns with large files. Are you aware of display-line-numbers-mode in emacs 26+? It should be much more performant.
I followed your suggestion and set global-display-line-numbers-mode. The problem persists and I can trigger it if I scroll up and down a few times: the results below are when the slowdown happens.
- command-execute 338,079,599 97%
- call-interactively 338,079,599 97%
- funcall-interactively 330,285,543 95%
- previous-line 314,753,104 91%
- line-move 314,753,104 91%
+ line-move-visual 298,623,462 86%
line-pixel-height 19,530 0%
+ scroll-down-command 7,516,324 2%
+ execute-extended-command 5,882,311 1%
+ kill-buffer 1,151,906 0%
+ delete-other-windows 874,913 0%
+ profiler-report-toggle-entry 64,336 0%
+ next-line 41,304 0%
right-char 1,024 0%
switch-to-buffer 321 0%
+ byte-code 7,739,564 2%
+ completing-read-default 54,492 0%
+ redisplay_internal (C function) 7,057,386 2%
+ timer-event-handler 25,344 0%
... 0 0%
I am not sure what functions to profile with elp-instrument-package. I tried julia- but the list of elp-results was empty.
That just means that it didn’t find any julia- functions called. Which doesn’t necessarily mean that it’s not julia-mode’s fault.
Is it all julia files where you see this behavior or only certain ones? Do you see the same behavior if you edit the file with a different major mode, e.g. python-mode? I just can’t imagine a scenario where julia-mode slowed down line-move-visual which is what’s showing a the root of most of your cpu time in the trace above. Maybe visual-line-mode is the problem?
Thank you for following up.
I saw the behavior on different Julia file.
When I tried this morning, python-mode, julia-mode and latex-mode were all working fine. Yesterday on the other hand, I could trigger the sluggishness (for julia-mode) after a few seconds of usage. I will try again later.
It is definitely associated with julia-mode. The slow-down goes away if I load a python script or a LaTeX file and reappears once I switch back to the Julia code.
Could you try using python-mode on the julia file where you experience sluggishness?
It is definitely the julia-mode. I move the cursor around until the Emacs becomes sluggish, I M-x python-mode and if I wait a couple of seconds without doing anything, the cursor is again responsive. I switch back to julia-mode and the cursor barely moves.
Since you’re just moving around in the file (not editing), my best guess is that it’s related to font-locking (my first guess would have been that it’s related to indentation). Could you try first changing syntax-propertize-function and seeing if sluggishness remains and then try font-lock-defaults? If either of those fixes the problem then we at least have a place to start looking. If not, then I’m stumped as to what’s going on.
If you can, it would also be good to check that you can reproduce this slowdown with emacs -q and manually loading julia-mode–to make sure this isn’t an interaction between julia-mode and another package.
For once the symbol ∈ slows down Emacs. If I replace it with in, scrolling is again fast.
function f(log::Dict, index::Int)
# Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam
# commodo urna in ultrices efficitur. Maecenas non mi ac ante
# pharetra rutrum sagittis ac dolor. Suspendisse ante augue,
# fermentum ac scelerisque sit amet, porttitor eget ante. Vivamus
# id nulla eget nunc molestie cursus nec quis lorem.
index ∈ keys(log)
# Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam
# commodo urna in ultrices efficitur. Maecenas non mi ac ante
# pharetra rutrum sagittis ac dolor. Suspendisse ante augue,
# fermentum ac scelerisque sit amet, porttitor eget ante. Vivamus
# id nulla eget nunc molestie cursus nec quis lorem.
end
Emacs 26.3, julia-mode 20200917.713