From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Michael Brand <michael.ch.brand@gmail.com>
Cc: Org Mode <emacs-orgmode@gnu.org>
Subject: Re: Opening an Org file slowed down
Date: Sat, 23 Nov 2013 11:52:45 +0100 [thread overview]
Message-ID: <87r4a7tmo2.fsf@gmail.com> (raw)
In-Reply-To: <CALn3zog7EMbb83axA4-Q57Sx8JfTDY7kowa_ggpoJi9_pgdUtQ@mail.gmail.com> (Michael Brand's message of "Fri, 22 Nov 2013 15:57:16 +0100")
Hello,
Michael Brand <michael.ch.brand@gmail.com> writes:
> On Mon, Nov 11, 2013 at 5:41 PM, Michael Brand
> <michael.ch.brand@gmail.com> 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 <n.goaziou@gmail.com>
>> 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
next prev parent reply other threads:[~2013-11-23 10:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 16:41 Opening an Org file slowed down Michael Brand
2013-11-11 17:02 ` Bastien
2013-11-24 16:36 ` Nicolas Goaziou
2013-11-22 14:57 ` Michael Brand
2013-11-23 10:52 ` Nicolas Goaziou [this message]
2013-11-24 13:49 ` Michael Brand
2013-11-24 16:25 ` Nicolas Goaziou
2013-11-25 18:45 ` Michael Brand
2013-11-26 17:28 ` Nicolas Goaziou
2013-11-26 19:53 ` Michael Brand
2013-11-26 20:09 ` Nicolas Goaziou
2013-11-26 20:50 ` Michael Brand
2013-11-26 22:19 ` Nicolas Goaziou
2013-11-27 9:24 ` Michael Brand
2013-11-27 11:27 ` Nicolas Richard
2013-11-27 13:35 ` Michael Brand
2013-11-27 17:10 ` Nicolas Richard
2013-11-27 22:06 ` Achim Gratz
2013-11-28 9:29 ` Nicolas Richard
2013-11-28 17:37 ` Michael Brand
2013-11-27 18:13 ` Achim Gratz
2013-11-27 19:44 ` Michael Brand
2013-11-27 20:05 ` Achim Gratz
2013-11-27 20:34 ` Michael Brand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r4a7tmo2.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=michael.ch.brand@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).