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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: sva-news <at> mygooglest.com, 15876 <at> debbugs.gnu.org
Subject: bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006
Date: Wed, 04 Dec 2013 19:53:03 +0200

> Date: Tue, 03 Dec 2013 19:09:10 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: sva-news <at> mygooglest.com, 15876 <at> 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.)

Previous Next

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