From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Wagner Subject: Re: Enriched/Org is a colorful Org Date: Fri, 12 Apr 2013 13:49:47 +0200 Message-ID: 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c28e8ef775c704da287f1a Return-path: Received: from eggs.gnu.org ([208.118.235.92]:49174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQcUI-00080d-JV for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 07:49:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQcUH-0008Cg-1F for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 07:49:50 -0400 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: Carsten Dominik Cc: Eli Zaretskii , Org Mode Mailing List --001a11c28e8ef775c704da287f1a Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > > On 12 apr. 2013, at 10:31, Eli Zaretskii wrote: > > >> From: Carsten Dominik > >> 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 > > --001a11c28e8ef775c704da287f1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

just want to add some observa= tion. I guess it has nothing to do with the display engine but it might be = somehow=A0related. I used to use line-mode to display line-numbers as a lef= t column on all my buffers.=A0
I noticed a very=A0painful=A0slowdown up to a totally unusable s= tate during working on very large org-files. It consisted of=A0coursework= =A0for a programming class and contained single headers with the student-id= numbers and a babel-code block in the headers body (hence, easily goes int= o 1000th of lines). I was happy with it since I could execute and proof eac= h submitted coursework within a single org-file and folding helped me to mo= ve quickly from one to the other coursework.
However, as longer as the list get as more it slowed down.=A0

After some=A0fiddling=A0and searching, I= noticed that the line-mode was kind of=A0struggling=A0with the org-mode te= xt-collapse feature. Whenever, I closed a header, it took large amount of t= imes to recalculate the line-numbers. Not sure where exactly line-mode did = consume the time. But it might as well be=A0related=A0to the redisplaying o= f the numbers. Switching off the line-mode made the time delay=A0disappear= =A0completely.=A0

Just an observation which might or might no= t=A0related=A0to 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. =A0The
> commentary at the beginning of the file might serve as an
> introduction, although it doesn't really touch the issue at hand.<= br> >
>> 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 redisp= lay
>> 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. =A0If 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<= br> > 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. =A0In 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, i= n
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. =A0Another important point to be aware of.


> Emacs moves by _screen_ lines, not by physical lines. =A0So 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. =A0And this is just to fi= nd
> 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. =A0But we are many times on<= br> > the edge, as the bug I cited and similar ones show.

Thanks again.

- Carsten


--001a11c28e8ef775c704da287f1a--