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: Wed, 11 Dec 2013 18:28:31 +0200 Message-ID: <83ob4nwdw0.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1386779506 29333 80.91.229.3 (11 Dec 2013 16:31:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Dec 2013 16:31:46 +0000 (UTC) Cc: sva-news@mygooglest.com, 15876@debbugs.gnu.org To: Dmitry Antipov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 11 17:31:51 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 1VqmhS-0002bI-Uu for geb-bug-gnu-emacs@m.gmane.org; Wed, 11 Dec 2013 17:31:51 +0100 Original-Received: from localhost ([::1]:58354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqmhS-0001HH-9c for geb-bug-gnu-emacs@m.gmane.org; Wed, 11 Dec 2013 11:31:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqmfs-0007Lh-PP for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2013 11:30:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vqmfk-0004tW-SD for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2013 11:30:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqmfk-0004rX-Ml for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2013 11:30:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vqmfi-0002mR-Uy for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2013 11:30:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Dec 2013 16:30: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.138677934210577 (code B ref 15876); Wed, 11 Dec 2013 16:30:02 +0000 Original-Received: (at 15876) by debbugs.gnu.org; 11 Dec 2013 16:29:02 +0000 Original-Received: from localhost ([127.0.0.1]:44066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vqmej-0002kN-CR for submit@debbugs.gnu.org; Wed, 11 Dec 2013 11:29:01 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:52465) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vqmef-0002k8-Og for 15876@debbugs.gnu.org; Wed, 11 Dec 2013 11:28:59 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MXN00F00HL09J00@a-mtaout22.012.net.il> for 15876@debbugs.gnu.org; Wed, 11 Dec 2013 18:28:33 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MXN00F82HRK3F60@a-mtaout22.012.net.il>; Wed, 11 Dec 2013 18:28:33 +0200 (IST) In-reply-to: <52A80BA8.3050403@yandex.ru> 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:81769 Archived-At: > Date: Wed, 11 Dec 2013 10:52:24 +0400 > From: Dmitry Antipov > CC: sva-news@mygooglest.com > > IMO the real problem is that redisplay sometimes isn't clever enough about requesting > font for the particular character (0x25b7 in our case): Not sure if this is for redisplay to solve. Redisplay just needs a face for displaying a character, it knows (almost) nothing about fonts and fontsets. It's the font selection machinery that needs to become smarter, I think. > Such a request produces a lot of font-entity objects, which are not needed (and becomes > reachable only via font cache) after the "best match" font is selected for the particular > character. Next, if font loading is too memory-intensive and gc_cons_threshold was hit, GC > clears font cache. Next cursor movement triggers redisplay, which in turn asks for the "best > match" for 0x25b7 again. If font cache is never cleared, this is acceptable because all possible > matches (represented as a vector of font-entities) are cached. But, if font cache is cleared, > font_list_entities calls to driver->list function, which creates a lot of font-entities again, > etc., etc. Right, this matches my observations. Did you succeed in finding which function in this call sequence is the performance bottleneck? > Until we have somewhat smarter redisplay, possible solution is to clear font cache when it > becomes larger than some specified size rather than at each GC. Now I have the virtual machine > with Windows 7 installed, and this fix looks reasonable for me. Could you also please try it? It solves the immediate problem with this single character, but if I add a few others from other Unicode blocks, the problem reappears. This is because the threshold of 4096 seems to be too low: I've seen the number go above 10K a couple of times. Anyway, what about the patch below? With it, the problem disappears even without your "threshold" based GC. We could be even more aggressive, and search also the face caches on all frames (but then, if found, the face needs to be cached on the current frame as well, before using it) -- this is left as an exercise ;-) The problem with this approach is that there's no guarantee we will find a "best-match" font for a character. However, I displayed etc/HELLO with and without the patch, and didn't see any difference. Maybe some font selection expert could tell if we lose anything important by going this way. Note that NS was already reusing the argument FACE (but it alone) in this way. --- src/fontset.c~ 2013-11-05 06:42:21.000000000 +0200 +++ src/fontset.c 2013-12-11 11:30:03.909213300 +0200 @@ -937,7 +937,6 @@ if (ASCII_CHAR_P (c) || face->fontset < 0) return face->ascii_face->id; -#ifdef HAVE_NS if (face->font) { /* Fonts often have characters in other scripts, like symbol, even if they @@ -946,9 +945,22 @@ perhaps be general? */ Lisp_Object font_object; XSETFONT (font_object, face->font); - if (font_has_char (f, font_object, c)) return face->id; + if (font_has_char (f, font_object, c)) + return face->id; + } + + for (face_id = 0; face_id < FRAME_FACE_CACHE (f)->used; face_id++) + { + struct face *this_face = FACE_FROM_ID (f, face_id); + + if (this_face != face && this_face->font) + { + Lisp_Object font_object; + XSETFONT (font_object, this_face->font); + if (font_has_char (f, font_object, c)) + return this_face->id; + } } -#endif eassert (fontset_id_valid_p (face->fontset)); fontset = FONTSET_FROM_ID (face->fontset);