Re: another example of org being slow, with some analysis

[Daniel Bausch <bausch@dvs.tu-darmstadt.de>]

Hi!

Nick Dokos <ndokos@gmail.com> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>
>> The output of the ELP profiler is here:
>>
>> ...
>> org-goto-line                       104  10.761145733  0.1034725551
>> ..
>> org-current-line                    66   6.8422078910  0.1036698165
>> ...
>
> I find these two difficult to explain: they account for the vast
> majority of the time, they don't call anything other than basic emacs
> lisp functions (which should be very fast) and they take an unbelievably
> long 0.1 s/call - I did a profile of a single call of each in a file
> where wc reports these stats:
>
>   12961  270362 4317977 /home/nick/lib/notes/notes.org
>
> and I got 0.002s for the first (going to line 6000, about the middle of
> the file) and 0.0004s for the second: a factor of 50 smaller for the
> first and a factor of 250 smaller for the second.
>
> Maybe it's an artifact of profiling, but maybe you can try instrumenting
> these two functions and doing something similar.  Do you still get 0.1s
> for each call?

Line 6000 is indeed quite "lame".  I have similar problems like Eric.  A
table recalculation at line 43868 takes about a minute at my quite fast
machine.  I also tracked that down to org-current-line.  One interesting
detail is that this depends on the buffer encoding.  With ASCII the
recalculation takes less than a second, with utf-8 about a minute.

I think it actually is not an org-mode problem but depends on how
(count-lines 1 (point)) works, as it is using regex searches for the
line endings.  I can imagine that the regex parser for utf-8 can be
inefficient.

Regards,
Daniel
-- 
MSc. Daniel Bausch
Research Assistant (Computer Science)
Technische Universität Darmstadt
http://www.dvs.tu-darmstadt.de/staff/dbausch