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 10:28:41 +0200 Message-ID: <87y4jgumo6.fsf@gelnhausen.dvs.informatik.tu-darmstadt.de> 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> 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]:35860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5rfL-0003zC-MO for emacs-orgmode@gnu.org; Fri, 19 Jun 2015 04:28:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5rfI-0002mQ-Th for emacs-orgmode@gnu.org; Fri, 19 Jun 2015 04:28:47 -0400 Received: from lnx500.hrz.tu-darmstadt.de ([130.83.156.225]:46144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5rfI-0002lL-Ji for emacs-orgmode@gnu.org; Fri, 19 Jun 2015 04:28:44 -0400 In-Reply-To: <87wpz016gd.fsf@ucl.ac.uk> (Eric S. Fraga's message of "Fri, 19 Jun 2015 08:51:46 +0100") 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 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.=20=20 > > 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. Maybe it is related (and maybe not - just some thoughts): Since some months I keep having a problem with my preferred encoding. Gentoo changed some things how the LC_... variables are set during boot. Now emacs daemon starts with "no encoding". I tried to fix that by inserting (prefer-coding-system 'utf-8) into mit ~/.emacs file, but that does not help. I still need to manually execute prefer-coding-system by hand and revert my org-file (which is automatically opened during login) with C-x RET r utf-8 every day. But if I remember correctly, I started observing the slowness of the table recalculation long before that change in Gentoo. Maybe it got worse since then but that might also be just because the file grew further. If anyone could give me a hint how to reliably set the preferred (or internal) encoding I could check wether it might have something to do with the system locale. (I can imagine that in some constellations there could be some otherwise unnecessary conversion happening. E.g. maybe utf-8 support is faster if the system locale is also utf-8.) Is there anything like an internal encoding in emacs at all? As far as I know I can type any character in any buffer regardless of the buffer encoding. I just cannot save the buffer if the encoding does not support a character. How is then a utf-8 *buffer* different from a buffer with no encoding (until being saved). Does goto-char work on bytes or really on characters? How does it maybe deal different with characters made up of multiple bytes in the on-disk encoding of the buffer? Regards, Daniel --=20 MSc. Daniel Bausch Research Assistant (Computer Science) Technische Universit=C3=A4t Darmstadt http://www.dvs.tu-darmstadt.de/staff/dbausch