Is Emacs buffer scroll/redisplay slow?

Is Emacs buffer scroll/redisplay slow?

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

Hi,

Out of curiosity, I timed 'emacs -Q' scrolling through an elisp buffer: I
started the timer
by hand and scrolled down for 1000 lines and it took 45s on Windows/WSL
and 35s on Windows/native.
This is on a pretty decent laptop (core i7, 32Gb ram, 4k display)
I don't care about the difference here, but overall,
I find it pretty slow. Is there something that could be done to enhance it?
What is the main bottleneck here?

Best regards,

Fabrice

[-- Attachment #2: Type: text/html, Size: 614 bytes --]

Re: Is Emacs buffer scroll/redisplay slow?

[Alan Mackenzie]

Hello, Fabrice.

On Sun, Jan 19, 2020 at 10:34:07 +0100, Fabrice Popineau wrote:
> Hi,

> Out of curiosity, I timed 'emacs -Q' ....

Which version of Emacs?

> .... scrolling through an elisp buffer: I started the timer by hand and
> scrolled down for 1000 lines ....

How, exactly, did you do the scrolling?  How did you stop the scrolling
at 1000 lines?  Do you get this slowness on any elisp buffer, or is it a
particular one?

> .... and it took 45s on Windows/WSL and 35s on Windows/native.

That is slow indeed.

> This is on a pretty decent laptop (core i7, 32Gb ram, 4k display) I
> don't care about the difference here, but overall, I find it pretty
> slow. Is there something that could be done to enhance it?  What is the
> main bottleneck here?

Have you tried profiling this scrolling, yet?  If not, I suggest you do,
with M-x profiler-start <CR> <CR>, running the scrolling, then M-x
profiler-report.  In the report buffer, hit <CR> to get successively
deeper results.

This may well give you an idea where the slowness is happening.

> Best regards,

> Fabrice

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Is Emacs buffer scroll/redisplay slow?

[Fabrice Popineau]

[-- Attachment #1.1: Type: text/plain, Size: 1577 bytes --]

Hi Alan,

Le dim. 19 janv. 2020 à 12:51, Alan Mackenzie <acm@muc.de> a écrit :

> Hello, Fabrice.
>
> On Sun, Jan 19, 2020 at 10:34:07 +0100, Fabrice Popineau wrote:
> > Hi,
>
> > Out of curiosity, I timed 'emacs -Q' ....
>
> Which version of Emacs?
>
> Current master.
Emacs is compiled with gcc 9.2.0 (MSYS2) and 7.4.0 (Ubuntu)
and CFLAGS = -g3 -O2 -gdwarf-2


> > .... scrolling through an elisp buffer: I started the timer by hand and
> > scrolled down for 1000 lines ....
>
> How, exactly, did you do the scrolling?  How did you stop the scrolling
> at 1000 lines?  Do you get this slowness on any elisp buffer, or is it a
> particular one?
>
> I used my phone timer. It was my init.el file but I get the same result
with dired.el

> .... and it took 45s on Windows/WSL and 35s on Windows/native.
>
> That is slow indeed.
>

Definitely.


>
> Have you tried profiling this scrolling, yet?  If not, I suggest you do,
> with M-x profiler-start <CR> <CR>, running the scrolling, then M-x
> profiler-report.  In the report buffer, hit <CR> to get successively
> deeper results.
>
> This may well give you an idea where the slowness is happening.
>

You are right. I should have tried it right away.

[image: image.png]

I am not sure there is anything unexpected in there.
The lisp machinery interpreting commands accounts for most of the time,
especially `completing-read-default' and I wonder why? Is it because of the
`make-composed-keymap' call
which occurs in `completing-read-default'?

Best regards,

Fabrice

[-- Attachment #1.2: Type: text/html, Size: 2719 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 126729 bytes --]

Re: Is Emacs buffer scroll/redisplay slow?

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 19 Jan 2020 15:24:19 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
>  > .... scrolling through an elisp buffer: I started the timer by hand and
>  > scrolled down for 1000 lines ....
> 
>  How, exactly, did you do the scrolling?  How did you stop the scrolling
>  at 1000 lines?  Do you get this slowness on any elisp buffer, or is it a
>  particular one?
> 
> I used my phone timer. It was my init.el file but I get the same result with dired.el

You didn't answer the question about the exact way of scrolling you
used.

Also, did you measure the CPU time it took, out of those 35 sec?  (I
assume the time you measured was elapsed time, yes?)

>  > .... and it took 45s on Windows/WSL and 35s on Windows/native.
> 
>  That is slow indeed.
> 
> Definitely.

Not necessarily.  The elapsed time has little to do with the speed we
scroll.

>  Have you tried profiling this scrolling, yet?  If not, I suggest you do,
>  with M-x profiler-start <CR> <CR>, running the scrolling, then M-x
>  profiler-report.  In the report buffer, hit <CR> to get successively
>  deeper results.
> 
>  This may well give you an idea where the slowness is happening.
> 
>  
> You are right. I should have tried it right away.
> 
> image.png
> 
> I am not sure there is anything unexpected in there. 
> The lisp machinery interpreting commands accounts for most of the time,
> especially `completing-read-default' and I wonder why? Is it because of the `make-composed-keymap' call
> which occurs in `completing-read-default'?

Which brings us back to the question of how did you scroll through
those 1000 lines.  I wouldn't expect to see completion code so high on
the profile, it almost sounds like the profile didn't measure the
important stuff.  (Was this the CPU profile or "memory" profile, btw?
The latter is largely useless.)

Re: Is Emacs buffer scroll/redisplay slow?

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

Le dim. 19 janv. 2020 à 16:28, Eli Zaretskii <eliz@gnu.org> a écrit :

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Sun, 19 Jan 2020 15:24:19 +0100
> > Cc: Emacs developers <emacs-devel@gnu.org>
> >
> >  > .... scrolling through an elisp buffer: I started the timer by hand
> and
> >  > scrolled down for 1000 lines ....
> >
> >  How, exactly, did you do the scrolling?  How did you stop the scrolling
> >  at 1000 lines?  Do you get this slowness on any elisp buffer, or is it a
> >  particular one?
> >
> > I used my phone timer. It was my init.el file but I get the same result
> with dired.el
>
> You didn't answer the question about the exact way of scrolling you
> used.


C-n or down arrow


> Also, did you measure the CPU time it took, out of those 35 sec?  (I
> assume the time you measured was elapsed time, yes?)
>
> >  > .... and it took 45s on Windows/WSL and 35s on Windows/native.
> >
> >  That is slow indeed.
> >
> > Definitely.
>
> Not necessarily.  The elapsed time has little to do with the speed we
> scroll.


We could expect emacs to be a little bit more reactive here.

Fabrice

[-- Attachment #2: Type: text/html, Size: 1921 bytes --]

Re: Is Emacs buffer scroll/redisplay slow?

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sun, 19 Jan 2020 16:34:17 +0100
> Cc: acm@muc.de, Emacs developers <emacs-devel@gnu.org>
> 
> C-n or down arrow

In that case, the elapsed time depends on the auto-repeat rate of your
keyboard, not just on the Emacs processing time, right?

>  Also, did you measure the CPU time it took, out of those 35 sec?  (I
>  assume the time you measured was elapsed time, yes?)
> 
>  >  > .... and it took 45s on Windows/WSL and 35s on Windows/native.
>  > 
>  >  That is slow indeed.
>  > 
>  > Definitely.
> 
>  Not necessarily.  The elapsed time has little to do with the speed we
>  scroll.
> 
> We could expect emacs to be a little bit more reactive here.

Please repeat the experiment in a fresh "emacs -Q" right after
starting it, then, after you finish scrolling, see what is the amount
of CPU time reported by utilities such as PsList.  Alternatively, look
at the load average value displayed by another Emacs session.

In my testing, when I lean on the DOWN arrow, the system load never
raises above 0.25, which means 3/4th of the time Emacs is idle.  My
keyboard's auto-repeat rate is 30 characters per second, which means
Emacs uses up about 7 msec (1000 / 30 / 4) to process every DOWN-arrow
keypress, and that includes all the redisplay code, JIT font-lock
etc.  I'm not sure I agree to call this "slow".

Re: Is Emacs buffer scroll/redisplay slow?

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

Le dim. 19 janv. 2020 à 17:02, Eli Zaretskii <eliz@gnu.org> a écrit :

>
> > We could expect emacs to be a little bit more reactive here.
>
> Please repeat the experiment in a fresh "emacs -Q" right after
> starting it, then, after you finish scrolling, see what is the amount
> of CPU time reported by utilities such as PsList.  Alternatively, look
> at the load average value displayed by another Emacs session.
>
> In my testing, when I lean on the DOWN arrow, the system load never
> raises above 0.25, which means 3/4th of the time Emacs is idle.  My
> keyboard's auto-repeat rate is 30 characters per second, which means
> Emacs uses up about 7 msec (1000 / 30 / 4) to process every DOWN-arrow
> keypress, and that includes all the redisplay code, JIT font-lock
> etc.  I'm not sure I agree to call this "slow".
>

Ok, thanks for the explanation which makes sense. I was afraid that elisp
be a drag here,
but it does not seem to account for too much. And it is on par with other
code editors (I tried
PyCharm to compare)

(BTW, my keyboard is also on the fastest auto-repeat setting ... but there
are ways to speed it
 over the limit imposed by the control panel of windows)

Fabrice

[-- Attachment #2: Type: text/html, Size: 1688 bytes --]

Re: Is Emacs buffer scroll/redisplay slow?

[Stefan Monnier]

>> > .... scrolling through an elisp buffer: I started the timer by hand and
>> > scrolled down for 1000 lines ....
[...]
>> .... and it took 45s on Windows/WSL and 35s on Windows/native.

1000 lines divided by 45s is about 22 lines per second.
If you did that with `C-n` it suggests you're simply using a keyboard
repeat rate of about 20 repetitions-per-second and Emacs is just neither
fast nor slow.  35s on native suggests the keyboard repeat rate is
(surprisingly) different, more like 30 repetitions-per-second.

If Emacs is slow in such a test, you'll notice because it will stop
refreshing the display at times (hoping that skipping the redisplay time
will help it keep up with the repeat rate).


        Stefan

Re: Is Emacs buffer scroll/redisplay slow?

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

Le dim. 19 janv. 2020 à 23:20, Stefan Monnier <monnier@iro.umontreal.ca> a
écrit :

> >> > .... scrolling through an elisp buffer: I started the timer by hand
> and
> >> > scrolled down for 1000 lines ....
> [...]
> >> .... and it took 45s on Windows/WSL and 35s on Windows/native.
>
> 1000 lines divided by 45s is about 22 lines per second.
> If you did that with `C-n` it suggests you're simply using a keyboard
> repeat rate of about 20 repetitions-per-second and Emacs is just neither
> fast nor slow.  35s on native suggests the keyboard repeat rate is
> (surprisingly) different, more like 30 repetitions-per-second.
>
> If Emacs is slow in such a test, you'll notice because it will stop
> refreshing the display at times (hoping that skipping the redisplay time
> will help it keep up with the repeat rate).
>

If I posted this, it is because looking at it, the cursor was like jumping
from line to line,
but it doesn't seem steady. Actually, I changed some setting to get a
faster autorepeat
and emacs keeps up when the time is down to 16s for 1000 lines, more than
twice as
fast.

Best regards,

Fabrice

[-- Attachment #2: Type: text/html, Size: 1613 bytes --]

Re: Is Emacs buffer scroll/redisplay slow?

[Stefan Monnier]

>> If Emacs is slow in such a test, you'll notice because it will stop
>> refreshing the display at times (hoping that skipping the redisplay time
>> will help it keep up with the repeat rate).

> If I posted this, it is because looking at it, the cursor was like
> jumping from line to line, but it doesn't seem steady. Actually,
> I changed some setting to get a faster autorepeat and emacs keeps up
> when the time is down to 16s for 1000 lines, more than twice as fast.

Ah, now you're talking!
Then yes, we have a speed problem.  Usually this depends on the
minor&major modes involved, so the profile is the best way to
start digging.  Could you try and redo the profile run, but where you
maximize the proportion of "line scrolling" that takes place during the
time between `profiler-start` and `profiler-report`?


        Stefan