From: Jacob Nielsen <jacob.nielsen@alcensoft.com>
To: emacs-orgmode@gnu.org
Subject: Re: another example of org being slow, with some analysis
Date: Mon, 22 Jun 2015 09:07:49 +0200 [thread overview]
Message-ID: <5amvzsw796.fsf@alcensoft.com> (raw)
In-Reply-To: 87k2uz953g.fsf@pierrot.dokosmarshall.org
Nick Dokos <ndokos@gmail.com> writes:
> Eric S Fraga <e.fraga@ucl.ac.uk> 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
next prev parent reply other threads:[~2015-06-22 7:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 16:28 another example of org being slow, with some analysis Eric S Fraga
2015-06-18 18:30 ` Nick Dokos
2015-06-19 6:19 ` Daniel Bausch
2015-06-19 6:34 ` Daniel Bausch
2015-06-19 7:37 ` Nicolas Goaziou
2015-06-19 7:51 ` Eric S Fraga
2015-06-19 8:28 ` Daniel Bausch
2015-06-19 9:43 ` Eric S Fraga
2015-06-22 6:48 ` Daniel Bausch
2015-06-23 11:16 ` Eric S Fraga
2015-06-19 13:53 ` Nick Dokos
2015-06-19 14:19 ` Eric S Fraga
2015-06-22 7:07 ` Jacob Nielsen [this message]
2015-06-18 19:54 ` Ivan Andrus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5amvzsw796.fsf@alcensoft.com \
--to=jacob.nielsen@alcensoft.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).