> 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.
>