Re: Iteration over frame->face_alist is a huge performance suck

[John Coughlin]

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