|
From: | Dmitry Gutov |
Subject: | Re: emacs rendering comparisson between emacs23 and emacs26.3 |
Date: | Sun, 5 Apr 2020 21:05:00 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
On 05.04.2020 19:15, Eli Zaretskii wrote:
Do you at least see CPU activity significantly go up when you do such mouse wheel scrolling?With what build? With the -O0 build with --enable-checking, I don't need the mouse: it's enough to lean on C-v and let the keyboard auto-repeat do its job -- one execution unit of the CPU maxes out after 5 to 10 C-v's. But with a -O2 optimized production build, Emacs keeps up both when I lean on C-v and when I turn the mouse wheel constantly.
Same here. And much as I like to see certain modes improved, I'm not sure this is only a performance problem. Because no matter how fast syntax highlighting is, you can lean on C-v faster.
IIRC, redisplay-dont-pause was supposed to help with things like this. But it doesn't (and it's obsolete), and apparently jit-lock does its thing anyway. This looks like the interesting part of the profile:
- scroll-up 5657 73% - jit-lock-function 5444 70% - jit-lock-fontify-now 5439 70% + jit-lock--run-functions 5431 70% + run-with-timer 5 0%Do you guys want to try (setq jit-lock-defer-time 0)? It comes with a certain visual downside, though.
Or, alternatively, (setq fast-but-imprecise-scrolling t). This var seems like a good idea in general, so we might consider going further with it.
[Prev in Thread] | Current Thread | [Next in Thread] |