From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.bugs Subject: bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006 Date: Mon, 02 Dec 2013 14:45:25 +0400 Message-ID: <529C64C5.2040509@yandex.ru> References: <867gcdiqji.fsf@somewhere.org> <86fvr09z55.fsf@somewhere.org> <83fvr01du4.fsf@gnu.org> <8638n0nj9p.fsf@somewhere.org> <86bo1eaelv.fsf@somewhere.org> <86r4a2vqbu.fsf@somewhere.org> <867gbqdisp.fsf@somewhere.org> <83haas5y88.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1385981180 5515 80.91.229.3 (2 Dec 2013 10:46:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Dec 2013 10:46:20 +0000 (UTC) Cc: 15876@debbugs.gnu.org To: Eli Zaretskii , Sebastien Vauban Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 02 11:46:24 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VnR1D-00038h-Gm for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Dec 2013 11:46:23 +0100 Original-Received: from localhost ([::1]:35117 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnR1C-00017r-VL for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Dec 2013 05:46:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnR11-00017h-Fc for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2013 05:46:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnR0s-0004OF-Pz for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2013 05:46:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40010) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnR0s-0004OB-Mc for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2013 05:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VnR0s-0002RT-AH for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2013 05:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Antipov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Dec 2013 10:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15876 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15876-submit@debbugs.gnu.org id=B15876.13859811389355 (code B ref 15876); Mon, 02 Dec 2013 10:46:02 +0000 Original-Received: (at 15876) by debbugs.gnu.org; 2 Dec 2013 10:45:38 +0000 Original-Received: from localhost ([127.0.0.1]:54029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnR0T-0002Qo-MA for submit@debbugs.gnu.org; Mon, 02 Dec 2013 05:45:38 -0500 Original-Received: from forward19.mail.yandex.net ([95.108.253.144]:57455) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnR0P-0002QX-P7 for 15876@debbugs.gnu.org; Mon, 02 Dec 2013 05:45:35 -0500 Original-Received: from smtp16.mail.yandex.net (smtp16.mail.yandex.net [95.108.252.16]) by forward19.mail.yandex.net (Yandex) with ESMTP id D581E112234E; Mon, 2 Dec 2013 14:45:26 +0400 (MSK) Original-Received: from smtp16.mail.yandex.net (localhost [127.0.0.1]) by smtp16.mail.yandex.net (Yandex) with ESMTP id 762F76A0616; Mon, 2 Dec 2013 14:45:26 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp16.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ymAQXOCFj0-jPnqLDSk; Mon, 2 Dec 2013 14:45:25 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1385981125; bh=yfIcDJIr7MPoLVkzE2/XTRlKiEhHdmRbWORyfNlAlcc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Y23zMLw/UmWw2na/dRKppdd7tNzUD+Jz4/p1za8qBPw+ARXirioNwwWjH6+pBcU8r UB5aQn5FZutt5kNegP9tL8IQ3OryQHdKTehIo4Qqjz7PiX7YcfCsBpbplVr3BtJflq 3McPMWCKhx/ikM3vH90U6WAqTJTLj7x3nTv9TI84= Authentication-Results: smtp16.mail.yandex.net; dkim=pass header.i=@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 In-Reply-To: <83haas5y88.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:81242 Archived-At: On 12/01/2013 08:31 PM, Eli Zaretskii wrote: > Dmitry, can you please look into this? I'm not familiar enough with > the font stuff, so I don't see how was the font-spec and its > font-entities stored in the font cache supposed to be referenced from > some other Lisp object, to make sure they are marked and not GC'ed. It should be easy - just use this: === modified file 'src/alloc.c' --- src/alloc.c 2013-12-01 22:33:13 +0000 +++ src/alloc.c 2013-12-02 09:32:55 +0000 @@ -5731,7 +5731,18 @@ eassert (!VECTOR_MARKED_P (ptr)); VECTOR_MARK (ptr); /* Else mark it. */ if (size & PSEUDOVECTOR_FLAG) - size &= PSEUDOVECTOR_SIZE_MASK; + { + size &= PSEUDOVECTOR_SIZE_MASK; + if (PSEUDOVECTOR_TYPEP (&ptr->header, PVEC_FONT)) + { + Lisp_Object tmp; + XSETFONT (tmp, ptr); + if (FONT_SPEC_P (tmp)) + fprintf (stderr, "mark font-spec\n"); + else if (FONT_ENTITY_P (tmp)) + fprintf (stderr, "mark font-entity\n"); + } + } and set breakpoints to fprintf(). I tried this and see that font-spec objects can be referenced from face caches: (gdb) bt 3 full #0 mark_vectorlike (ptr=0x13178b8) at ../../trunk/src/alloc.c:5741 tmp = {i = 20019389} size = 13 i = 20019389 #1 0x00000000005ec050 in mark_object (arg=...) at ../../trunk/src/alloc.c:6084 ptr = 0x13178b8 pvectype = 15 obj = {i = 20019384} cdr_count = 0 #2 0x00000000005eb92b in mark_face_cache (c=0x15049b0) at ../../trunk/src/alloc.c:5839 face = 0x18d2050 i = 2 j = 15 (More stack frames follow...) I.e. (struct face *)0x18d2050 has font-spec object in lface[15]. But the most of font-spec and font-entity objects are referenced via staticpro'ed globals Vfontset_table and ft_face_cache. For example: (gdb) bt 16 #0 mark_vectorlike (ptr=0x129a288) at ../../trunk/src/alloc.c:5741 #1 0x00000000005ec050 in mark_object (arg=...) at ../../trunk/src/alloc.c:6084 #2 0x00000000005eb5f0 in mark_vectorlike (ptr=0x1296428) at ../../trunk/src/alloc.c:5752 #3 0x00000000005ec050 in mark_object (arg=...) at ../../trunk/src/alloc.c:6084 #4 0x00000000005eb5f0 in mark_vectorlike (ptr=0x129a4d0) at ../../trunk/src/alloc.c:5752 #5 0x00000000005ec050 in mark_object (arg=...) at ../../trunk/src/alloc.c:6084 #6 0x00000000005eb725 in mark_char_table (ptr=0x1788060) at ../../trunk/src/alloc.c:5779 #7 0x00000000005eb717 in mark_char_table (ptr=0x12094d0) at ../../trunk/src/alloc.c:5776 #8 0x00000000005eb717 in mark_char_table (ptr=0x13e2578) at ../../trunk/src/alloc.c:5776 #9 0x00000000005eb717 in mark_char_table (ptr=0xd85188) at ../../trunk/src/alloc.c:5776 #10 0x00000000005ec02c in mark_object (arg=...) at ../../trunk/src/alloc.c:6069 #11 0x00000000005eb5f0 in mark_vectorlike (ptr=0xd85080) at ../../trunk/src/alloc.c:5752 #12 0x00000000005ec050 in mark_object (arg=...) at ../../trunk/src/alloc.c:6084 #13 0x00000000005eac4b in Fgarbage_collect () at ../../trunk/src/alloc.c:5489 #14 0x0000000000563500 in maybe_gc () at ../../trunk/src/lisp.h:4462 #15 0x000000000060ec3e in Ffuncall (nargs=2, args=0x7fffffff0790) at ../../trunk/src/eval.c:2756 (gdb) bt 16 full ... #13 0x00000000005eac4b in Fgarbage_collect () at ../../trunk/src/alloc.c:5489 nextb = 0x0 stack_top_variable = 0 '\000' i = 1491 message_p = false count = 140 start = {tv_sec = 1385977872, tv_nsec = 656653658} retval = {i = 13914818} tot_before = 0 ... (gdb) p staticvec[1491] $8 = (Lisp_Object *) 0xd25cb0 > In any case, it seems like they are never marked on Windows, because > if I set a breakpoint in the line marked below: > > /* If font-spec is not marked, most likely all font-entities > are not marked too. But we must be sure that nothing is > marked within OBJ before we really drop it. */ > for (i = 0; i < size; i++) > if (VECTOR_MARKED_P (XFONT_ENTITY (AREF (XCDR (obj), i)))) > break; > > if (i == size) <<<<<<<<<<<<<<<<<<<<< > drop = 1; > } > > with a condition i != size, that breakpoint never breaks. The best way to hit this breakpoint is to run something like: (defun bloat-font () (interactive) (let ((fonts (x-list-fonts "*"))) (while fonts (condition-case nil (set-frame-font (car fonts)) (error nil)) (setq fonts (cdr fonts)) (redisplay)))) (This is X-specific; I believe there should be a similar MS-Windows method). Subtle "triangle example" works just fine for me (with default font used by GTK3 build and 'emacs -Q' at least). Also I'm curious how to reproduce this issue with X. In particular, how to find a font so "heavy" that an attempt to load it creates a lot of Lisp data (hundreds Kbytes, enough to reach gc_cons_threshold each time)? Dmitry