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.
1 Like
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?
1 Like
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?
1 Like
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.
1 Like
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