Re: [O] long code blocks making Org Mode very slow

[Grant Rettke]

I will play around with it. I didn't try to do a ECM.

Playing around with it tonight starting with

open /Applications/Emacs.app --new --args -Q

So using 8.2.10.

Sometimes I can get a slow down when calling `next-line' repeatedly.

I will play around with it and report if I get something reproducible
and an ECM.
Grant Rettke
--
address@hidden | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
“All creativity is an extended form of a joke.” --Kay
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson


On Wed, Jul 22, 2015 at 7:41 AM, Nick Dokos <address@hidden> wrote:
> Angus M <address@hidden> writes:
>
>>> When I have the cursor inside of the code block for the code, moving
>>> up or done one line or one page takes 2-3 seconds.
>>> Grant Rettke
>>> --
>>
>> Thanks for confirming that you also experience the slow-down.
>>
>> I think that the only way to remedy this is to modify the
>> 'org-src-font-lock-fontify-block' function in org-src.el to allow
>> just-in-time fontification, (rather than the current complete
>> re-fontification of the whole code block upon any changes).
>>
>
> I'm not convinced that this is the reason. I tried with a simple file
> (a headline, some text, a source code block with 7K lines of python -
> the decimal.py file from the standard python library - and some more
> text).
>
> I set org-src-fontify-natively to nil (through a local variable in
> the file). Adding text after the code block was OK but adding text
> before the code block was very slow. If fontification were the problem,
> I'd expect both to be fast.
>
> I did a profile with elp and it seems to me that the problem is footnote
> detection:
>
> --8<---------------cut here---------------start------------->8---
> org-activate-footnote-links                                   7           
> 13.397064245  1.9138663207
> org-footnote-next-reference-or-definition                     7           
> 13.396982566  1.9138546524
> org-footnote-in-valid-context-p                               378         
> 13.384084804  0.0354076317
> org-in-block-p                                                322         
> 13.146482877  0.0408275865
> org-between-regexps-p                                         2576        
> 12.544080215  0.0048695963
> org-footnote-at-reference-p                                   189         
> 6.7601071689  0.0357677627
> org-footnote-at-definition-p                                  189         
> 6.6263815400  0.0350602197
> org-element--parse-to                                         15          
> 0.41858634    0.027905756
> org-element--cache-sync                                       18          
> 0.3965463360  0.0220303520
> org-fontify-meta-lines-and-blocks                             14          
> 0.3946110120  0.0281865008
> org-fontify-meta-lines-and-blocks-1                           14          
> 0.3944775729  0.0281769695
> org-element--current-element                                  7           
> 0.3642047120  0.0520292445
> ...
> --8<---------------cut here---------------end--------------->8---
>
> I didn't check how org-between-regexps-p and org-footnote-at-*-p are
> related, but those three seem to account for the lion's share of the
> time.
>
> BTW, org-src-font-lock-fontify-block calls font-lock-fontify-buffer
> which is not supposed to be called from lisp programs: the doc string
> suggests using font-lock-ensure or font-lock-flush. I tried the first
> but it did not make any difference in the speed. But I guess it should
> be changed.
>
> --
> Nick
>
>