[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: Emacs design and architecture. How about copy-on-write?
Date: Thu, 21 Sep 2023 10:25:26 +0300

> 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 08:41:29 +0800
> Eli Zaretskii <eliz@gnu.org> writes:
> > This sounds as if you are talking about something other than Emacs,
> > really.  Try running some day with all the redisplay optimizations
> > turned off and with enough windows/frames visible, and you will see
> > how far we are from 60 fps goal.  There's a lot of room for
> > improvement even without being a video game, just an editor.
> We don't have a "60FPS goal."  "Frames per second" is a metric that
> applies to programs which are perpetually redrawing their windows,
> either as fast as the monitor refreshes or as fast as the CPU permits.

We don't have to interpret "60 fps" too literally.  A possible
Emacs-friendly interpretation is "60 display updates per second", for
example.  Here's an experiment to try:

  (global-set-key "\C-z" (function (lambda () (interactive) (scroll-up 1))))

Then visit a large file and lean on C-z.

Another possibility is to lean of C-v.

> I don't type 60 characters per second -- so there is no reason for Emacs
> to display at 60 frames per second.

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.

> > Or visit Reddit and see how many users complain that Emacs is slower
> > in displaying stuff than, say, VSCode.
> I seriously doubt redisplay performance is the cause of their plights.

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

> There's also the old experiment where Eric Naggum disabled garbage
> collection messages, yielding a visible speedup.

That's orthogonal to the issue at hand.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]