From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Opening an Org file slowed down Date: Sat, 23 Nov 2013 11:52:45 +0100 Message-ID: <87r4a7tmo2.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkApJ-0007q7-Di for emacs-orgmode@gnu.org; Sat, 23 Nov 2013 05:52:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VkApB-0006e0-AT for emacs-orgmode@gnu.org; Sat, 23 Nov 2013 05:52:37 -0500 Received: from mail-ea0-x234.google.com ([2a00:1450:4013:c01::234]:58441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkApA-0006dl-O9 for emacs-orgmode@gnu.org; Sat, 23 Nov 2013 05:52:29 -0500 Received: by mail-ea0-f180.google.com with SMTP id f15so1043769eak.39 for ; Sat, 23 Nov 2013 02:52:26 -0800 (PST) In-Reply-To: (Michael Brand's message of "Fri, 22 Nov 2013 15:57:16 +0100") 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: Michael Brand Cc: Org Mode Hello, Michael Brand writes: > On Mon, Nov 11, 2013 at 5:41 PM, Michael Brand > 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 >> 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