Hi! Nick Dokos <ndo...@gmail.com> writes:
> Eric S Fraga <e.fr...@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
