[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: Dmitry Gutov
Subject: Re: Emacs design and architecture. How about copy-on-write?
Date: Wed, 20 Sep 2023 22:39:47 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 20/09/2023 17:51, Eli Zaretskii wrote:
Emacs is not a video game, for which the touchstone of performance is a
measurement taken in ``frames-per-second''.  It is a text editor that
only updates the display subsequent to an editing operation.  That is,
unless you perform more than 60 edits per second and expect an
intervening redisplay after each edit.
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.

Or visit Reddit and see how many users complain that Emacs is slower
in displaying stuff than, say, VSCode.

I see those voices, and see the couter-opinions as well. But note that those that do complain so are likely comparing the simple case of one-buffer-one-frame (so redisplaying multiple windows in parallel wouldn't quite fix that).

So their complaints can be compounded from different things:

- Anybody using CC Mode with large files might notice latency during editing from running before/after-change-functions (because its design involves keeping the syntax info up-to-date in the whole buffer).

- People using LSP likely see better performance because of VC Code being able to parse the server's output in a different thread (or web worker? I haven't seen the exact design). LSP-Mode folks wrote a POC branch of Emacs which parallelizes the JSON parsing as well: https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance/ Some work toward mainlining this feature (perhaps after generalizing) could help. Or maybe the "multiple concurrent interpreters" approach could yield similar gains.

- The "snazzy" mode-line packages sometimes slow things down more than expected.

reply via email to

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