From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii Subject: Re: Enriched/Org is a colorful Org Date: Fri, 12 Apr 2013 16:03:10 +0300 Message-ID: <8338uvaokx.fsf@gnu.org> References: <87a9p79gnv.fsf@gmail.com> <20130410095450.GA31506@kuru.dyndns-at-home.com> <83a9p69x0c.fsf@gnu.org> <262C4E11-6D4B-4033-A619-1702CC8D0F94@gmail.com> <86fvyycfa9.fsf@somewhere.org> <83vc7t9dr1.fsf@gnu.org> <8461B483-8CC4-4D37-94BD-5CBEED773ADE@gmail.com> <83ip3s9rp8.fsf@gnu.org> <5A8E6625-33C1-4B94-A78E-B08268C57A5F@gmail.com> <83fvyw9mkh.fsf@gnu.org> Reply-To: Eli Zaretskii Return-path: Received: from eggs.gnu.org ([208.118.235.92]:39774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQddN-0005Yg-DO for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 09:03:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQddI-0001bC-O5 for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 09:03:17 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:38260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQddI-0001au-G7 for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 09:03:12 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0ML500D0080MJB00@a-mtaout21.012.net.il> for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 16:03:10 +0300 (IDT) In-reply-to: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Torsten Wagner Cc: emacs-orgmode@gnu.org, carsten.dominik@gmail.com > Date: Fri, 12 Apr 2013 13:49:47 +0200 > From: Torsten Wagner > Cc: Eli Zaretskii , Org Mode Mailing List > just want to add some observation. I guess it has nothing to do with the > display engine but it might be somehow related. I used to use line-mode to > display line-numbers as a left column on all my buffers. > I noticed a very painful slowdown up to a totally unusable state during > working on very large org-files. It consisted of coursework for a > programming class and contained single headers with the student-id numbers > and a babel-code block in the headers body (hence, easily goes into 1000th > of lines). I was happy with it since I could execute and proof each > submitted coursework within a single org-file and folding helped me to move > quickly from one to the other coursework. > However, as longer as the list get as more it slowed down. > > After some fiddling and searching, I noticed that the line-mode was kind > of struggling with the org-mode text-collapse feature. Whenever, I closed a > header, it took large amount of times to recalculate the line-numbers. Not > sure where exactly line-mode did consume the time. But it might as well > be related to the redisplaying of the numbers. Switching off the line-mode > made the time delay disappear completely. So this was an Org file with only 1 level of headers, but with large blocks of text between the headers, is that right? Can you show an example of such babel-code block? I'd like to look into the slowdown and find its reasons. In general, linum does exactly what defeats redisplay optimizations: it modifies overlays in a post-command-hook. But that doesn't mean this was the reason for the slow operation you saw, it could be something else. If you can easily produce a recipe for recreating the problem, it might be worthwhile to file an Emacs bug report. Thanks.