GNU bug report logs - #41200
Displaying a tooltip with x-show-tip gets very slow as more faces are defined

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
Cc: 41200 <at> debbugs.gnu.org, andlind <at> gmail.com
Subject: bug#41200: Displaying a tooltip with x-show-tip gets very slow as more faces are defined
Date: Fri, 15 May 2020 20:28:11 +0300

> Cc: 41200 <at> debbugs.gnu.org, Anders Lindgren <andlind <at> gmail.com>
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Fri, 15 May 2020 12:22:53 -0400
> 
> >>> face_hash_table?
> >>
> >> Thanks, good idea.  I also liked Stefan's frame_face_map.
> > 
> > "Map" is too general, IMO, it doesn't tell enough about the kind of
> > object it is.
> 
> Got it.  Is face_table better? (that was Stefan's other suggestion)

Is anything wrong with face_hash_table?

> > I thought about updating the alist when the hash-table is modified.
> > Since you always know whether the face is already in the hash-table,
> > you don't need to scan the alist looking for it.
> 
> Would that be done in C, or in any place where frame-new-face-defaults is modified?  (for example, edebug changes face-new-frame-defaults in one place; if we keep the alist in addition to the hash table, would it modify both or would there be a C mechanism that mirrors hash-table modifications to the alist?)

The latter was what I had in mind.

> I have a variant of the patch that keeps the alist variable, but I fear that it's worse than removing it: since changes to the alist won't be propagated to the hash table, it might be better to error out with a compilation error?

Not sure yet, it depends on how this is used.

> Btw, I have one more question: some callers of face-list seems to rely on the order of faces added to it, so it would be better to preserve that order.  Since hash-tables are not necessarily ordered, should I sort faces by face-id before returning them? 

Yes, I think so.

> > I think the problem is that tab-line is declared a basic face, but its
> > defface form is not in faces.el.
> 
> Ah, good catch.  Current there's a defface for tab-bar in lisp/tab-bar, and since that's preloaded it works, but the defface for tab-line is in lisp/tab-line.el and so isn't preloaded.
> Should I move both to faces.el?

Yes, I think so.

> >>> I'm not sure I understand why do you need to look at the existing
> >>> face's 'face' property?  The original code didn't.
> >>
> >> The original code iterated over face-frame-alist in the order in which entries were added to it.  If I understand correctly, iteration order isn't guaranteed on hash tables (is it?), so I had to find a different source of truth for these.
> > 
> > Maybe we should store the ID with the face?  I think we wanted to get
> > rid of the 'face' property of the faces at some point.
> 
> Sounds reasonable; but where would we store it?  Right now faces are just symbols, right?

Don't hash-tables allow us to store more than one item in each slot?

> > No, I was asking why not start with it as nil and actually make a
> > hash-table when we first need it.
> 
> Oh, I thought it would be simpler to always have a hash table instead of having to sanity check every time.

What is the default size of a hash-table?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.