Re: Enriched/Org is a colorful Org

[Torsten Wagner <torsten.wagner@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4085 bytes --]

Hi,

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.

Just an observation which might or might not related to the later
discussion.

Torsten




On 12 April 2013 12:56, Carsten Dominik <carsten.dominik@gmail.com> wrote:

>
> On 12 apr. 2013, at 10:31, Eli Zaretskii <eliz@gnu.org> wrote:
>
> >> From: Carsten Dominik <carsten.dominik@gmail.com>
> >> Date: Fri, 12 Apr 2013 09:13:47 +0200
> >> Cc: emacs-orgmode@gnu.org
> >>
> >>> Just search xdisp.c for "overlay", you will see the story quite
> >>> clearly, I think.
> >>
> >> My Sunday pleasure reading project.
> >
> > Good luck, and let me know if you need something explained.  The
> > commentary at the beginning of the file might serve as an
> > introduction, although it doesn't really touch the issue at hand.
> >
> >> So the reason that the combination with hi-line is slow is because
> >> hl-line is using post-command-hook to move its overlay, and redisplay
> >> of a full window with org-mode is slow because so much stuff is
> >> hidden and Emacs makes a full re-evaluation of what needs
> >> to be displayed?
> >
> > Right.  If hi-line (or any similar mode) is off, then at least
> > horizontal cursor motion should be fast, because then Emacs knows that
> > nothing changed, and finding the place where to put the cursor on the
> > same line it was before is relatively easy.
> >
> > But even C-n and C-p is quite another story in an Org buffer: Emacs
> > needs to determine where that puts point, and doing so generally means
> > traversing all of the hidden parts of the buffer between the line
> > which was current and the new current line.  In a complex Org buffer,
> > that could easily be many thousands of buffer positions.
>
> I guess outline mode does have the exact same problem in this case, in
> fact any mode with large amount of hidden text.
>
> >
> > Also, recall that, under line-move-visual, which is nowadays on by
> > default,
>
> Not in my setup, but since it the default, yes, this causes more
> issues.  Another important point to be aware of.
>
>
> > Emacs moves by _screen_ lines, not by physical lines.  So a
> > simple C-n must internally emulate display to find the next line
> > visible on the screen by traversing the buffer one character at a time
> > and taking note of each and every text property and overlay in
> > between, until it finds the buffer position whose screen coordinates
> > are [X,Y+N], where [X,Y] are the coordinates of the previous cursor
> > position and N is the line height in pixels.  And this is just to find
> > where point will be; then the screen must actually be redisplayed,
> > which might mean more work, if the new position of point requires
> > scrolling, e.g. if cursor went off the scroll margins or whatever.
> >
> > We only get reasonably fast performance with all this complexity
> > because our machines are incredibly fast.  But we are many times on
> > the edge, as the bug I cited and similar ones show.
>
> Thanks again.
>
> - Carsten
>
>

[-- Attachment #2: Type: text/html, Size: 5264 bytes --]