Re: Enriched/Org is a colorful Org

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 12 Apr 2013 13:49:47 +0200
> From: Torsten Wagner <torsten.wagner@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Org Mode Mailing List <emacs-orgmode@gnu.org>
> 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.