emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Opening an Org file slowed down


From: Nicolas Goaziou
Subject: Re: [O] Opening an Org file slowed down
Date: Sat, 23 Nov 2013 11:52:45 +0100

Hello,

Michael Brand <address@hidden> writes:

> On Mon, Nov 11, 2013 at 5:41 PM, Michael Brand
> <address@hidden> wrote:
>> I noticed that to open an Org file with a minimal example generated
>> like this slowed down:
>>
>> #+BEGIN_SRC sh
>>   #!/bin/sh
>>   echo '* a'
>>   for ((i = 0; i < 400; i++)); do
>>       echo '  - b'
>>       echo '    :PROPERTIES:'
>>       echo '    :END:'
>>   done
>> #+END_SRC
>>
>> Bisecting shows that release_8.2.1-161-g205e586 is fast and
>>
>> release_8.2.1-162-gb392750
>>
>>     commit b3927501081b1dab15540591d55f016ed4f9f948
>>     Author: Nicolas Goaziou <address@hidden>
>>     Date:   Sat Nov 2 15:48:36 2013 +0100
>>
>>         Prevent flagging drawers in example blocks
>>
>> is slow. Today's release_8.2.2-192-ge3033d3 is between fast and slow but
>> mainly it also slows down disproportionate to increasing the number 400
>> above. Emacs is 24.3.2 (with -q).
>>
>> My use case is that "  - b" is in fact "  * b" and is converted in a
>> hook to "*** b" with the help of "hidestarsfile" from "fileconversion"
>> described here:
>> http://orgmode.org/worg/org-hacks.html#hidestarsfile
>
> I still see the same problem with today's release_8.2.3c-271-gd0e8e57.
> Can you reproduce it with the test Org file from my recipe?

Yes, I can reproduce it.

I pushed a fix that should halve the time, but it will still be slow.

`org-element-at-point' is linear by the number of elements before point
in the current section. Therefore, parsing /all/ elements in a section
will be quadratic by the number of elements in the section.

With caching, an interesting coefficient is introduced before that n^2.
So, even though it's still quadratic, it will not be noticeable for most
situations (e.g. less that a couple hundreds elements in a section).

In you example, you're introducing 800 elements in the same section.
Among them 400 need to be parsed before the buffer is displayed. You're
way above the limit.

So, what can be done?

Please note that the parsing process is inherently linear, since we're
in a context-dependent grammar. Thus, there's not much to do about the
parsing algorithm.

However, the cache is always up-to-date. So, we are not bound to start
again from headline if we can find a cached element between it and the
point. The closer, the better.

I think there's room for improvement in this area. An idea could be to
start `org-element-at-point' with an opportunistic search. Before going
back to the headline, we could, indeed, `search-backward' on
`org-element-paragraph-start' a couple of times and check if location
found is already cached. This would work well when parsing successively
elements in the same section or when editing the current paragraph.

Anyway any idea must be carefully profiled.


Regards,

-- 
Nicolas Goaziou



reply via email to

[Prev in Thread] Current Thread [Next in Thread]