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: Sun, 01 Dec 2013 18:31:51 +0200 Message-ID: <83haas5y88.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1385915596 8856 80.91.229.3 (1 Dec 2013 16:33:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Dec 2013 16:33:16 +0000 (UTC) Cc: 15876@debbugs.gnu.org To: Sebastien Vauban , Dmitry Antipov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 01 17:33:21 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 1Vn9xO-0006ZD-AW for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Dec 2013 17:33:18 +0100 Original-Received: from localhost ([::1]:60284 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vn9xN-0000wq-Vj for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Dec 2013 11:33:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vn9xG-0000wZ-Oa for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2013 11:33:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vn9x9-0007T1-90 for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2013 11:33:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vn9x9-0007Sw-5g for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2013 11:33:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vn9x8-0007YR-7n for bug-gnu-emacs@gnu.org; Sun, 01 Dec 2013 11:33: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: Sun, 01 Dec 2013 16:33: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.138591552828973 (code B ref 15876); Sun, 01 Dec 2013 16:33:02 +0000 Original-Received: (at 15876) by debbugs.gnu.org; 1 Dec 2013 16:32:08 +0000 Original-Received: from localhost ([127.0.0.1]:53369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vn9wF-0007XE-TJ for submit@debbugs.gnu.org; Sun, 01 Dec 2013 11:32:08 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:57500) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vn9wC-0007Wb-4c for 15876@debbugs.gnu.org; Sun, 01 Dec 2013 11:32:05 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MX400M00Z3MER00@a-mtaout22.012.net.il> for 15876@debbugs.gnu.org; Sun, 01 Dec 2013 18:31:57 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MX400M5VZ9737B0@a-mtaout22.012.net.il>; Sun, 01 Dec 2013 18:31:55 +0200 (IST) In-reply-to: <867gbqdisp.fsf@somewhere.org> 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:81206 Archived-At: > From: "Sebastien Vauban" > Cc: 15876@debbugs.gnu.org > Date: Fri, 29 Nov 2013 22:01:10 +0100 > > Eli Zaretskii wrote: > >> From: "Sebastien Vauban" > >> Cc: 15876@debbugs.gnu.org > >> Date: Tue, 26 Nov 2013 21:52:05 +0100 > >> > >> > So what is the minimum .emacs that will cause the problem? > >> > >> That does it: > >> > >> --8<---------------cut here---------------start------------->8--- > >> ;; highlight trailing whitespaces in all modes > >> (setq-default show-trailing-whitespace t) > >> > >> (setq org-ellipsis " \u25B7") ; string > >> --8<---------------cut here---------------end--------------->8--- > > > > And this makes Emacs slow in scrolling for any file you visit? Or > > just in Org buffers? > > No problem, with the same files, if I put them in `text-mode'. So, it becomes > apparent with Org. > > Remember I told there were similar speed problems with some Gnus buffer, but I > haven't tested them again. > > > If the latter, perhaps your Org files are special in some way, because > > the ones I tried don't show any slowdown I could sense. > > They aren't special, for two reasons: > > - They're not mine; they're public Org files taken from the Worg project ("Wiki > Org"). > > - They work perfectly in Emacs rev 114715: no performance degradation > whatsoever. > > For the sake of clarity, I've redone a comparison of the two different Emacs > (r114715 and the recent r115235) on the same two Org files: > > - ChangeLog.org (1,156 bytes) > http://code.ohloh.net/file?fid=s6NzuuiKK0Nlga9EF-Vh8KzVXiw&cid=SNfK_pTfQmo&s=&fp=19410&mp=&projSelected=true#L0 > > - org-faq.org (164,174 bytes) > http://code.ohloh.net/file?fid=Jk4U4mwQtJT_5LfYpl3sBLhj42s&cid=SNfK_pTfQmo&s=&fp=19410&mp=&projSelected=true#L0 I looked at this issue. It has nothing to do with org-ellipsis, or the Org mode in general. To reproduce it, it's enough to do just this: emacs -Q C-x 8 RET 25b7 RET Now try moving the cursor across the line that displays the triangle character u+25B7. If you are on Windows 7, this will use the BatangChe font for the triangle, and every redisplay operation, even cursor motion, will be extremely slow. (On XP, this font is not installed, and even if I install it, I'm unable to trigger the same problem, for some reason.) This slowdown seems to be caused by this commit: revno: 114735 committer: Dmitry Antipov branch nick: trunk timestamp: Mon 2013-10-21 14:11:25 +0000 message: Do not allow font caches to grow too large. * alloc.c (compact_font_cache_entry, compact_font_caches): New functions or stub if not HAVE_WINDOW_SYSTEM. (compact_undo_list): Factor out from Fgarbage_collect. Add comment. (mark_face_cache): Mark face font. Move down to avoid extra prototypes. (mark_terminals): Do not mark font cache here. (Fgarbage_collect): Call compaction functions described above. Adjust comment. What happens is that the above-mentioned font causes a lot of consing, when loaded (perhaps because it supports many different Unicode blocks). That triggers GC immediately after redisplay; GC calls compact_font_caches, which for some reason decides that the font-specs in the font cache can be removed. Then the next redisplay needs the deleted font again, so it again loads it, which causes consing, which triggers GC, etc. etc. If I disable the compacting, like this: static void compact_font_caches (void) { struct terminal *t; for (t = terminal_list; t; t = t->next_terminal) { Lisp_Object cache = TERMINAL_FONT_CACHE (t); #if 0 if (CONSP (cache)) { Lisp_Object entry; for (entry = XCDR (cache); CONSP (entry); entry = XCDR (entry)) XSETCAR (entry, compact_font_cache_entry (XCAR (entry))); } #endif mark_object (cache); } } then the problem goes away. 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. 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. If you see something different on X, please tell which code is responsible for marking those font-entities and/or the font-spec's in the font cache. (I guess you meant mark_face_cache to do that, but it marks fonts, not font-entities or font-spec's.)