From: "John Coughlin" <jack@johnbcoughlin.com>
To: "Eli Zaretskii" <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Iteration over frame->face_alist is a huge performance suck
Date: Fri, 02 Jul 2021 06:39:43 -0700 [thread overview]
Message-ID: <4c146d56-2074-4ba0-9672-42439e5b0108@www.fastmail.com> (raw)
In-Reply-To: <83o8bljkxl.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]
> see bug#41200
Thank you for the pointer. There was no discussion of frame_face_alist I could see on this mailing list. It looks like that thread (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41200) satisfied itself of all the issues raised, except for the copyright release of the author of the final version of the patch, which is a shame. Hopefully it can be merged soon.
Thanks a lot,
-Jack
On Thu, Jul 1, 2021, at 11:20 PM, Eli Zaretskii wrote:
> > Date: Thu, 01 Jul 2021 20:58:07 -0700
> > From: "John Coughlin" <jack@johnbcoughlin.com>
> >
> > Recently I have been investigating slowdowns in overall responsiveness
> > and snappiness in my emacs setup, which arise during the course of
> > normal work. I attached a sampling profiler to the process
> > (Instruments on MacOS), and recorded ten or so seconds of
> > mashing the movement cursors in my org-agenda window. The result is
> > that 93.4% of the total samples are inside of the function
> > lface_from_face_name_no_resolve, in xfaces.c. The culprit seems to be
> > a large association list, frame->face_list, which in my current
> > session contains over 1000 faces.
>
> This is a known problem. The current implementation of face lookup
> doesn't scale well enough to such usage patterns.
>
> > - This may be less of a problem in vanilla emacs, but some packages create faces
> > that result in quite deep recursive calls to merge_named_face. Each such frame
> > in the stack (I observed upwards of 50 such frames with my org-agenda button
> > mashing) is doing its own face lookups.
>
> Yes, and watch out for faces that inherit from other faces, which
> themselves inherit from other faces.
>
> > So, what should be done about this?
>
> We have a solution designed and almost implemented: see bug#41200.
> Unfortunately, its development stalled. It would be good to finalize
> the code, resolve the issues that were found with it (as discussed in
> the bug thread), and install it.
>
[-- Attachment #2: Type: text/html, Size: 2876 bytes --]
prev parent reply other threads:[~2021-07-02 13:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 3:58 Iteration over frame->face_alist is a huge performance suck John Coughlin
2021-07-02 6:20 ` Eli Zaretskii
2021-07-02 13:39 ` John Coughlin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c146d56-2074-4ba0-9672-42439e5b0108@www.fastmail.com \
--to=jack@johnbcoughlin.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.