GNU bug report logs - #15876
24.3.50; Highly degraded performance between rev 114715 and 115006

Previous Next

Full log

Message #161 received at 15876 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: sva-news <at> mygooglest.com, 15876 <at> debbugs.gnu.org, dmantipov <at> yandex.ru,
 jan.h.d <at> swipnet.se
Subject: Re: bug#15876: 24.3.50;
 Highly degraded performance between rev 114715 and 115006
Date: Fri, 13 Dec 2013 20:53:24 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>         Jan Djärv
>  <jan.h.d <at> swipnet.se>,
>         sva-news <at> mygooglest.com, 15876 <at> debbugs.gnu.org
> Date: Fri, 13 Dec 2013 11:45:15 -0500
> 
> > aren't typical use cases, holding ~200M which we can't reuse is worth
> > trying to fix, IMHO.
> 
> Actually, we *can* reuse that memory, but only by selecting those
> fonts again.  I agree with Eli: the benefit is very small.

The problem is not with fonts, it is with font-entities stored in a
font cache.  For some reason that I cannot understand, Emacs needs to
consult the font cache when it looks for a font suitable for
displaying a character, even when the character was already displayed,
and the face (including the font) used for its display was already
realized and cached in the frame's face cache.  I don't understand the
font selection machinery enough to see why is that necessary.  But the
upshot of all this is that the face and the font do exist, but the
face-entities for that font are GC'ed, and that triggers the whole
process of discovering the available fonts in the available fontsets
again, each time Emacs displays the character.  So if that discovery
process conses a lot, it is likely to trigger GC, which will discard
the font-entities, etc. etc.

Previous Next

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