Re: Is Emacs buffer scroll/redisplay slow?

[Eli Zaretskii]

> From: Fabrice Popineau <address@hidden>
> Date: Sun, 19 Jan 2020 15:24:19 +0100
> Cc: Emacs developers <address@hidden>
> 
>  > .... 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.)