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

[Eli Zaretskii]

> Cc: 41200@debbugs.gnu.org, Anders Lindgren <andlind@gmail.com>
> From: Clément Pit-Claudel <cpitclaudel@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?