> Date: Fri, 12 Apr 2013 13:49:47 +0200 > From: Torsten Wagner <torsten.wag...@gmail.com> > Cc: Eli Zaretskii <e...@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.
