15

When running previous-line, C-p or <up> the cursor jumps up a line without any issues or lags. When running next-line, C-n or <down> the cursor properly jumps down a line, but with a significant lag. When I hold the down key I can't even see the point moving, it just appears somewhere below. I ran the Emacs profiler and it seems that the culprit is cl-position. What it works out to be is that previous-line literally just moves the cursor, while next-line runs a whole lot of functions.

Profiler output

What is the issue and how can it be fixed?

Damian Chrzanowski
  • 733
  • 5
  • 14

4 Answers4

29

I have found an answer to my question through narrowing down the naughty bit and googling. I have managed to reduce the lag 10 TIMES!!!! I mean....It is insane on how much computing power next-line was using to move a cursor down ?!?!

The fix:

Put this code into your init.el: (setq auto-window-vscroll nil)

The proof:

Lag reduced significantly

Now next-line does not trigger line-move-partial therefore reducing the lag. I do not remember setting up auto-window-vscroll to t. It wasn't anywhere in any of my .el files, I am not sure how it got set to t to begin with. So if anyone has an performance issues with the cursor movement, then the above fix will reduce the lag from about 50%-80% cpu time to 5% cpu time !!!

To quickly check if you are affected just run C-h v auto-window-vscroll. If it is set to t you might be having major performance issues. Verify with the Emacs profiler if the cursor movement does indeed cause a lag.

Best of luck fellow Emacs lovers!!!

Source of fix

Damian Chrzanowski
  • 733
  • 5
  • 14
3

I'm not absolutely sure what is the problem, but your profiler report seems to indicate that posn-at-point performs more redisplay than expected, which in turns causes recomputation of the mode-line, and that powerline should make more effort to memoize its computation for the modeline.

IOW, I suggest you M-x report-emacs-bug and you might also report a bug to the powerline maintainers.

Stefan
  • 26,154
  • 3
  • 46
  • 84
1

I noticed that my doom-modeline is also contributing to the lag. In fact, it is said in the doc of doom-modeline:

 ;; If it brings the sluggish issue, disable `doom-modeline-enable-word-count' or
 ;; remove the modes from `doom-modeline-continuous-word-count-modes'.

After setting (setq doom-modeline-enable-word-count nil) I got a noticeable speed-up in cursor movements.

Jason
  • 161
  • 4
0

It looks like you're using powerline. In particular, you're display the projectile project name in your modeline. There have been some improvements to the projectile package recently that have mitigated some of that. Make sure you're up to date.

https://github.com/bbatsov/projectile/issues/1212

https://github.com/bbatsov/projectile/pull/1213

It's also possible to memoize functions that the modeline calls. I've done this a lot on my modeline to make it very fast.

Aaron Jensen
  • 367
  • 3
  • 9
  • The problem has already been solved, Projectile or Power line were not the problem – Damian Chrzanowski Mar 02 '18 at 14:15
  • I'm glad you got it sorted. Your profile did point to the slowdown coming from projectile. It could be that setting auto-window-vscroll to nil just causes emacs to skip unnecessary mode-line calculations. Any way, glad you got it sorted! – Aaron Jensen Mar 03 '18 at 17:08
  • That is a good point. I really didn't have the time to check which package was the problem. Thanks for the suggestions though! – Damian Chrzanowski Mar 03 '18 at 17:25