all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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 --]

      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.