From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Bausch Subject: Re: another example of org being slow, with some analysis Date: Fri, 19 Jun 2015 08:19:14 +0200 Message-ID: <877fr0w78d.fsf@gelnhausen.dvs.informatik.tu-darmstadt.de> References: <87ioalhtfa.fsf@delle7240.chemeng.ucl.ac.uk> <87vbekc1iy.fsf@alphaville.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5pe8-0000mx-5h for emacs-orgmode@gnu.org; Fri, 19 Jun 2015 02:19:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5pe2-0004YF-E6 for emacs-orgmode@gnu.org; Fri, 19 Jun 2015 02:19:24 -0400 Received: from lnx500.hrz.tu-darmstadt.de ([130.83.156.225]:46672) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5pe2-0004Xg-4w for emacs-orgmode@gnu.org; Fri, 19 Jun 2015 02:19:18 -0400 In-Reply-To: <87vbekc1iy.fsf@alphaville.usersys.redhat.com> (Nick Dokos's message of "Thu, 18 Jun 2015 14:30:29 -0400") 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: Nick Dokos Cc: emacs-orgmode@gnu.org Hi! Nick Dokos writes: > Eric S Fraga 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 --=20 MSc. Daniel Bausch Research Assistant (Computer Science) Technische Universit=C3=A4t Darmstadt http://www.dvs.tu-darmstadt.de/staff/dbausch