From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006 Date: Fri, 13 Dec 2013 17:22:37 +0200 Message-ID: <837gb86aiq.fsf@gnu.org> 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> <529C64C5.2040509@yandex.ru> <834n6r5edh.fsf@gnu.org> <529DAAED.9000504@yandex.ru> <83ob4y3wi5.fsf@gnu.org> <529DF416.7070807@yandex.ru> <83txeo33ls.fsf@gnu.org> <52A01D59.7030304@yandex.ru> <83lhzz2oal.fsf@gnu.org> <52A80BA8.3050403@yandex.ru> <83ob4nwdw0.fsf@gnu.org> <52A8A850.8040302@yandex.ru> <83k3fb6yvb.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1386948253 18658 80.91.229.3 (13 Dec 2013 15:24:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Dec 2013 15:24:13 +0000 (UTC) Cc: sva-news@mygooglest.com, 15876@debbugs.gnu.org, dmantipov@yandex.ru To: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 13 16:24:18 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 1VrUbA-00060H-SL for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2013 16:24:17 +0100 Original-Received: from localhost ([::1]:43102 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrUbA-0003rD-9P for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2013 10:24:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrUb2-0003h4-9R for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 10:24:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrUax-0007Ji-Cl for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 10:24:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrUax-0007JX-8D for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 10:24:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VrUaw-0004Ie-Pv for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2013 10:24:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Dec 2013 15:24: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.138694820716479 (code B ref 15876); Fri, 13 Dec 2013 15:24:02 +0000 Original-Received: (at 15876) by debbugs.gnu.org; 13 Dec 2013 15:23:27 +0000 Original-Received: from localhost ([127.0.0.1]:48641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VrUaL-0004Hh-Hf for submit@debbugs.gnu.org; Fri, 13 Dec 2013 10:23:26 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:55084) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VrUa8-0004HL-8W for 15876@debbugs.gnu.org; Fri, 13 Dec 2013 10:23:22 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MXR00E00407V800@a-mtaout22.012.net.il> for 15876@debbugs.gnu.org; Fri, 13 Dec 2013 17:22:38 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MXR00E0541PMG90@a-mtaout22.012.net.il>; Fri, 13 Dec 2013 17:22:38 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il 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:81880 Archived-At: > From: Jan Djärv > Date: Wed, 11 Dec 2013 20:50:12 +0100 > Cc: Dmitry Antipov , > Kenichi Handa , > 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?