Re: Emacs design and architecture. How about copy-on-write?

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: dmitry@gutov.dev,  yantar92@posteo.net,  acm@muc.de,
>   incal@dataswamp.org,  emacs-devel@gnu.org
> Date: Thu, 21 Sep 2023 15:48:58 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Leaning on a key, as in the examples above, will produce input events
> > at a relatively high rate (albeit usually lower than 60 per sec), each
> > one of them requiring some kind of redisplay.  Even leaning on C-f
> > triggers redisplay at high rate.  I suggest to try this in various
> > non-dash-Q configurations and see how we fare in these situations.
> > There's nothing outlandish in expecting an editor to keep up with
> > high-rate scrolling commands, I hope you agree with that at least.
> 
> I agree, but slow scrolling is not redisplay's fault.  If I type:
> 
>   M-: (jit-lock-fontify-all) RET
> 
> or enable c-ts-mode prior to leaning on C-v, within an Emacs session
> with a 790 MiB resident set that has been executing continuously for 32
> days, then Emacs scrolls (xterm.c and xdisp.c) as fast as any other
> editor on my system.

Then try leaning on C-n or C-p _after_ everything is already
fontified.  You will still see that Emacs sometimes cannot keep up,
especially if lines are not too short.

You will never succeed in convincing me that our redisplay is as fast
as I'd like it to be.  I've seen too many proofs to the contrary.

> > You can doubt all you want, but some of what they say is definitely
> > related to redisplay, IMNSHO.
> 
> Any examples?

Sorry, you will have to find them yourself.