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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 03 Dec 2013 19:09:10 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: sva-news@mygooglest.com, 15876@debbugs.gnu.org
> 
> According to comments at the beginning of font.h, FONT_ENTITY_INDEX slot
> of font object should reference font-entity from which this font object
> is opened.  But now I'm seeing that this slot is always Qnil.  I.e. the
> following patch should help:
> 
> === modified file 'src/font.c'
> --- src/font.c	2013-10-29 16:11:50 +0000
> +++ src/font.c	2013-12-03 12:10:28 +0000
> @@ -196,6 +196,7 @@
>         if (! NILP (AREF (entity, FONT_EXTRA_INDEX)))
>   	font->props[FONT_EXTRA_INDEX]
>   	  = Fcopy_alist (AREF (entity, FONT_EXTRA_INDEX));
> +      font->props[FONT_ENTITY_INDEX] = entity;
>       }
>     if (size > 0)
>       font->props[FONT_SIZE_INDEX] = make_number (pixelsize);
> 
> With this patch applied, I can hit 'break' at alloc.c:5327 even if
> configured with --without-xft; this should help MS-Windows build too.

Thanks.

Indeed, with this patch, I now see several font-entities spared from
being GC'ed.  Unfortunately, this doesn't solve the slow-down with
that character and font, while ifdef'ing away this fragment from
compact_font_caches:

      if (CONSP (cache))
	{
	  Lisp_Object entry;

	  for (entry = XCDR (cache); CONSP (entry); entry = XCDR (entry))
	    XSETCAR (entry, compact_font_cache_entry (XCAR (entry)));
	}

does solve it.

So there's some other factor at work here that causes us to drop
portions of the font cache that we shouldn't have.

What kind of information do I need to collect on Windows to make it
clear where the problem is?  Can you suggest some code that would
collect the necessary information, or ideas for writing such code?
(It's inconvenient to collect the data in GDB, since many objects are
marked at this point, and printing them from GDB crashes Emacs.)