[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: Po Lu
Subject: Re: Emacs design and architecture. How about copy-on-write?
Date: Thu, 21 Sep 2023 08:41:29 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

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.

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

If you open the GUI inspector tool of any Gtk+ program, then enable its
"frames per second" counter, you will quickly recognize that a GUI
program such as a text editor seldom, if ever, redraws itself at such a

> 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.
It's much more likely to be GC, slow fontification code, or post command
hooks, all three of which present with near identical symptoms.

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

reply via email to

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