bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Wed, 11 Dec 2013 20:50:12 +0100
> Cc: Dmitry Antipov <dmantipov@yandex.ru>,
>  Kenichi Handa <handa@gnu.org>,
>  15876@debbugs.gnu.org,
>  sva-news@mygooglest.com
> 
> > Jan, Ken'ichi, would you please comment on this?  Are we losing
> > something by reusing already loaded fonts that support a given
> > character, as opposed to looking for the "best-match" font?
> 
> See discussion starting here 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15138#29:
> 
> Kenichi Handa wrote:
> 
> I agree that this change improves font selection for
> symbols, but it's not good for many scripts for which just
> having a glyph is not enough.  For instance, if the default
> font has Hindi glyphs but doesn't have the OTF features for
> Hindi script, we must find another proper font for Hindi.
> 
> How about modifying the current fontset mechanism as this?
> 
> (1) Allow t for FONT-SPEC of set-fontset-font to tell that
>     the default font should be tried.
> (2) Modiyf the default fontset to include `t' as the
>     font-spec for scripts/characters for which the default
>     font is ok.

I see.  But then why does the NS build still use a variant of that
approach?  How is it exempt from what Handa-san wrote above?

Anyway, the more I look into this problem, the more I'm beginning to
think that we should simply revert this font-cache compacting.  Here's
my reasoning:

 . The latest approach suggested by Dmitry (before my suggestion) was
   to use some more or less arbitrary threshold to decide whether or
   not to compact the font caches.  I tried playing with that
   approach, and found that I need to bump the threshold to something
   like 30K, before I get reasonable performance in a buffer full of
   unusual characters.

 . But raising the threshold higher simply means we defer the
   compaction more and more, to the point where we have no compaction
   at all.  IOW, doing this is equivalent to deleting that code
   altogether.

 . I also tried a different approach: compact only those font-entities
   that don't match any font that is still used by some face on some
   frame.  (I used font_match_p for that.)  This seems to work, except
   that font_match_p is evidently not safe enough to be used in the
   middle of GC -- I got crashes a few times.  When it did work, it
   again prevented the compaction, as if the compacting code were not
   there at all.

So let me turn the table and ask what do we gain by this compaction?
The original motivation was here:

  http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00740.html

but it was mainly about not releasing the fonts.  With the current
trunk, if I run that bloat-font function, after disabling the
compaction code, I see only a small increase in the memory footprint,
something like 30MB, at least on Windows.  Do you see something
different on X?

If the growth of the memory footprint is small even in such an extreme
situation, then perhaps we don't need this compaction?