From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Nielsen Subject: Re: another example of org being slow, with some analysis Date: Mon, 22 Jun 2015 09:07:49 +0200 Message-ID: <5amvzsw796.fsf@alcensoft.com> References: <87ioalhtfa.fsf@delle7240.chemeng.ucl.ac.uk> <87vbekc1iy.fsf@alphaville.usersys.redhat.com> <877fr0w78d.fsf@gelnhausen.dvs.informatik.tu-darmstadt.de> <87wpz016gd.fsf@ucl.ac.uk> <87k2uz953g.fsf@pierrot.dokosmarshall.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6vpq-0006qn-Ba for emacs-orgmode@gnu.org; Mon, 22 Jun 2015 03:08:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z6vpn-0007C5-36 for emacs-orgmode@gnu.org; Mon, 22 Jun 2015 03:08:02 -0400 Received: from plane.gmane.org ([80.91.229.3]:43110) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6vpm-0007Bu-Sa for emacs-orgmode@gnu.org; Mon, 22 Jun 2015 03:07:59 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Z6vpk-0007l2-50 for emacs-orgmode@gnu.org; Mon, 22 Jun 2015 09:07:56 +0200 Received: from port802.ds1-ly.adsl.cybercity.dk ([212.242.223.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Jun 2015 09:07:56 +0200 Received: from jacob.nielsen by port802.ds1-ly.adsl.cybercity.dk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Jun 2015 09:07:56 +0200 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: emacs-orgmode@gnu.org Nick Dokos writes: > Eric S Fraga writes: > >> On Friday, 19 Jun 2015 at 08:19, Daniel Bausch wrote: >> >> [...] >> >>> 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. >> >> Adding some data: my table is at line 8438 in the buffer but character >> position 398345 (I have very long lines as I use visual-line-mode in org >> exclusively with org-indent). I do use utf-8 encoding. >> >> I have just tried updating the table on a different laptop (i7-2760, 8 >> cores, 8 GB RAM, Ubuntu) and it was very fast. >> >> The two laptops are running different versions of emacs (tracking latest >> emacs developments on Ubuntu and Debian testing lead to different >> versions unfortunately) so my gut feeling is that there is an emacs >> issue here and possibly one related to utf-8 as Daniel suggests. >> >> I'll try to do more instrumenting on my other laptop when I get a >> chance. >> > What is the setting of cache-long-scans you are using? Does it differ > on the two laptops? > > Ivan Andrus suggested setting it to nil, but it seems that for this > case, leaving it at t (the default) should be much faster. But there > may be a bug in the cache code. It *should* be faster but it isn't :-( At least not when using org mode. I've had this in my org file where I recalculate tables regularly. # -*- cache-long-scans: nil; -*- # This makes forward-line much faster and thus org-goto-line and thus org-table-sum (C-c +) Before it took forever to recalculate tables; now it's fast :-) Org mode file with 10500 lines. The tables I recalculate are at the bottom. Current org mode version is 8.2.10 (org-plus-contrib 20150601) Best regards, Jacob