Slow/poor responsiveness in org files

Slow/poor responsiveness in org files

[Tim Cross]

About a week or so ago, I updated emacs from bzr and saw that org 7.7
had been merged in. Since then, I have also noticed a distinct delay
when performing various editing operations within org files. For
example, killing a line wiht C-k in an org mode buffer is taking about
4 seconds!

I updated emacs and tried again with emacs -Q and got the same result

My version is 24.0.50 bzr relno 105475

Has anyone else seen this? What would be the best way to debug this
sort of issue, emacs profiler?

Tim

Re: Slow/poor responsiveness in org files

[Bastien]

Hi Tim,

Tim Cross <theophilusx@gmail.com> writes:

> About a week or so ago, I updated emacs from bzr and saw that org 7.7
> had been merged in. Since then, I have also noticed a distinct delay
> when performing various editing operations within org files. For
> example, killing a line wiht C-k in an org mode buffer is taking about
> 4 seconds!

This might come either from Org and/or from Emacs.

> I updated emacs and tried again with emacs -Q and got the same result
>
> My version is 24.0.50 bzr relno 105475
>
> Has anyone else seen this? 

Yes.

> What would be the best way to debug this sort of issue, emacs
> profiler?

Four tests would be useful:

- Emacs 23 + Org 7.4
- Emacs 23 + Org 7.7
- Emacs 24 (from trunk) + Org 7.4
- Emacs 24 (from trunk) + Org 7.7

For each case, M-x elp-instrument-package RET org-mode RET to
see if there is any particular function that takes significantly
more time.  

I'm busy fixing small bugs in Org 7.7 but fixing such slowniness
is high priority and such tests would really help me *a lot*.

Thanks in advance!

-- 
 Bastien

Re: Slow/poor responsiveness in org files

[Antoine Levitt]

18/08/11 09:49, Bastien
> Hi Tim,
>
> Tim Cross <theophilusx@gmail.com> writes:
>
>> About a week or so ago, I updated emacs from bzr and saw that org 7.7
>> had been merged in. Since then, I have also noticed a distinct delay
>> when performing various editing operations within org files. For
>> example, killing a line wiht C-k in an org mode buffer is taking about
>> 4 seconds!
>
> This might come either from Org and/or from Emacs.
>
>> I updated emacs and tried again with emacs -Q and got the same result
>>
>> My version is 24.0.50 bzr relno 105475
>>
>> Has anyone else seen this? 
>
> Yes.
>
>> What would be the best way to debug this sort of issue, emacs
>> profiler?
>
> Four tests would be useful:
>
> - Emacs 23 + Org 7.4
> - Emacs 23 + Org 7.7
> - Emacs 24 (from trunk) + Org 7.4
> - Emacs 24 (from trunk) + Org 7.7
>
> For each case, M-x elp-instrument-package RET org-mode RET to
> see if there is any particular function that takes significantly
> more time.  
>
> I'm busy fixing small bugs in Org 7.7 but fixing such slowniness
> is high priority and such tests would really help me *a lot*.
>
> Thanks in advance!

Also try setting bidi-display-reordering to nil and see if that changes
anything.

Re: Slow/poor responsiveness in org files

[Tim Cross]

On Thu, Aug 18, 2011 at 9:53 PM, Antoine Levitt
<antoine.levitt@gmail.com> wrote:
> 18/08/11 09:49, Bastien
>> Hi Tim,
>>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> About a week or so ago, I updated emacs from bzr and saw that org 7.7
>>> had been merged in. Since then, I have also noticed a distinct delay
>>> when performing various editing operations within org files. For
>>> example, killing a line wiht C-k in an org mode buffer is taking about
>>> 4 seconds!
>>
>> This might come either from Org and/or from Emacs.
>>
>>> I updated emacs and tried again with emacs -Q and got the same result
>>>
>>> My version is 24.0.50 bzr relno 105475
>>>
>>> Has anyone else seen this?
>>
>> Yes.
>>
>>> What would be the best way to debug this sort of issue, emacs
>>> profiler?
>>
>> Four tests would be useful:
>>
>> - Emacs 23 + Org 7.4
>> - Emacs 23 + Org 7.7
>> - Emacs 24 (from trunk) + Org 7.4
>> - Emacs 24 (from trunk) + Org 7.7
>>
>> For each case, M-x elp-instrument-package RET org-mode RET to
>> see if there is any particular function that takes significantly
>> more time.
>>
>> I'm busy fixing small bugs in Org 7.7 but fixing such slowniness
>> is high priority and such tests would really help me *a lot*.
>>
>> Thanks in advance!
>
> Also try setting bidi-display-reordering to nil and see if that changes
> anything.
>
>
>

OK, will do.

As Bastien indicates this is a known problem, I will assume there is
an existing bug report and won't create a new one. I will post my
results back here. Given the combinations to test, this will take some
work and some time.

One question I do have, how do I run emacs bzr trunk with org 7.4? Is
it sufficient to just ensure some 7.4 load directory is  first in the
load path? Also, what is the url to get 7.4?

Tim

Re: Slow/poor responsiveness in org files

[Bastien]

Hi Tim,

Tim Cross <theophilusx@gmail.com> writes:

> OK, will do.

Thanks in advance!

> As Bastien indicates this is a known problem, I will assume there is
> an existing bug report and won't create a new one. I will post my
> results back here. Given the combinations to test, this will take some
> work and some time.

Please first try what Antoine suggested.

> One question I do have, how do I run emacs bzr trunk with org 7.4? Is
> it sufficient to just ensure some 7.4 load directory is  first in the
> load path? 

I think so.

> Also, what is the url to get 7.4?

http://orgmode.org/org-7.4.tar.gz

Or get Org from git:

  ~$ git clone git://orgmode.org/org-mode.git

and checkout commit 597e2863377fb8763cf6951e3b4e777b4616300d

HTH,

-- 
 Bastien

Re: Slow/poor responsiveness in org files

[Tim Cross]

On Sat, Aug 20, 2011 at 10:23 AM, Bastien <bzg@altern.org> wrote:
> Hi Tim,
>
> Tim Cross <theophilusx@gmail.com> writes:
>
>> OK, will do.
>
> Thanks in advance!
>
>> As Bastien indicates this is a known problem, I will assume there is
>> an existing bug report and won't create a new one. I will post my
>> results back here. Given the combinations to test, this will take some
>> work and some time.
>
> Please first try what Antoine suggested.
>
>> One question I do have, how do I run emacs bzr trunk with org 7.4? Is
>> it sufficient to just ensure some 7.4 load directory is  first in the
>> load path?
>
> I think so.
>
>> Also, what is the url to get 7.4?
>
> http://orgmode.org/org-7.4.tar.gz
>
> Or get Org from git:
>
>  ~$ git clone git://orgmode.org/org-mode.git
>
> and checkout commit 597e2863377fb8763cf6951e3b4e777b4616300d
>
> HTH,
>
> --
>  Bastien
>

OK, will try to do later this weekend. Was going to check the bidi
settings first as the changing of the default for bidi mode and the
merge of 7.7 occured quite close - probably within the same update for
me. I am a daily org user and had not noticed any performance issues
with 7.4.

Need to wait until my work completes the current major system update
outage to get access to my large org file that I want to test with.
Should be able to do this tomorrow.

Tim

P.S. I did notice no significant performance problems with very small
org test files. It would seem you need to cross some size threshold
before you notice the performance impact.

Re: Slow/poor responsiveness in org files

[Tim Cross]

SOLVED!

Adding the line

(setq bidi-display-reordering nil)

to my org-mode-hook has fixed the problem. Cursor movement and editing
operations are now usable and the delays are gone.

This was with Emacs 24.0.50 revno 105525

Unfortunately, I now find I have emacs generating a backtrace when I
try to quite with the error
void-function bidi-string-mark-left-to-right, but I think that is
unrelated and just coincidental.

Tim


On Sat, Aug 20, 2011 at 10:53 AM, Tim Cross <theophilusx@gmail.com> wrote:
> On Sat, Aug 20, 2011 at 10:23 AM, Bastien <bzg@altern.org> wrote:
>> Hi Tim,
>>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> OK, will do.
>>
>> Thanks in advance!
>>
>>> As Bastien indicates this is a known problem, I will assume there is
>>> an existing bug report and won't create a new one. I will post my
>>> results back here. Given the combinations to test, this will take some
>>> work and some time.
>>
>> Please first try what Antoine suggested.
>>
>>> One question I do have, how do I run emacs bzr trunk with org 7.4? Is
>>> it sufficient to just ensure some 7.4 load directory is  first in the
>>> load path?
>>
>> I think so.
>>
>>> Also, what is the url to get 7.4?
>>
>> http://orgmode.org/org-7.4.tar.gz
>>
>> Or get Org from git:
>>
>>  ~$ git clone git://orgmode.org/org-mode.git
>>
>> and checkout commit 597e2863377fb8763cf6951e3b4e777b4616300d
>>
>> HTH,
>>
>> --
>>  Bastien
>>
>
> OK, will try to do later this weekend. Was going to check the bidi
> settings first as the changing of the default for bidi mode and the
> merge of 7.7 occured quite close - probably within the same update for
> me. I am a daily org user and had not noticed any performance issues
> with 7.4.
>
> Need to wait until my work completes the current major system update
> outage to get access to my large org file that I want to test with.
> Should be able to do this tomorrow.
>
> Tim
>
> P.S. I did notice no significant performance problems with very small
> org test files. It would seem you need to cross some size threshold
> before you notice the performance impact.
>

Re: Slow/poor responsiveness in org files

[Eli Zaretskii]

> Date: Mon, 22 Aug 2011 10:52:49 +1000
> From: Tim Cross <theophilusx@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> SOLVED!
> 
> Adding the line
> 
> (setq bidi-display-reordering nil)
> 
> to my org-mode-hook has fixed the problem. Cursor movement and editing
> operations are now usable and the delays are gone.

Please don't consider this a solution.  bidi-display-reordering should
not slow down redisplay to a degree that makes Emacs unusable.  And
setting bidi-display-reordering to nil means that R2L scripts cannot
be used in Org buffers, which is clearly unacceptable.

If you can send me the offending file, that would be the best.
Failing that, please answer the following questions:

 . How large is the Org file, in bytes?

 . How many entries do you have in it, including distribution between
   levels (i.e., how many entries of 2nd level do you have, on
   average, per each 1st-level entry, how many 3rd-level entries per
   each 2nd-level entry, etc.)?

 . Is the slowdown the same at the beginning of the file, the end of
   the file, and in the middle?

 . Which commands exhibit the slowdown?  Are C-f/C-b slow?  How about
   left and right arrows?  C-v/M-v? Up/down arrows?

 . Does the slowdown go away after "M-x show-all RET"?

 . Do you have any minor modes, in addition to Org mode, turned on in
   those buffers, and if so, which ones?  Please include any sub-modes
   of Org in the list.

 . Does setting bidi-paragraph-direction to `left-to-right' eliminate
   the slowdown?

With this info, I can try reproducing the problem and looking for a
proper solution.

TIA

Re: Slow/poor responsiveness in org files

[Tim Cross]

On Mon, Aug 22, 2011 at 3:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 22 Aug 2011 10:52:49 +1000
>> From: Tim Cross <theophilusx@gmail.com>
>> Cc: emacs-devel@gnu.org
>>
>> SOLVED!
>>
>> Adding the line
>>
>> (setq bidi-display-reordering nil)
>>
>> to my org-mode-hook has fixed the problem. Cursor movement and editing
>> operations are now usable and the delays are gone.
>
> Please don't consider this a solution.  bidi-display-reordering should
> not slow down redisplay to a degree that makes Emacs unusable.  And
> setting bidi-display-reordering to nil means that R2L scripts cannot
> be used in Org buffers, which is clearly unacceptable.
>
> If you can send me the offending file, that would be the best.
> Failing that, please answer the following questions:
>

Sorry, I cannot send the offending file as it contains sensitive information.

>  . How large is the Org file, in bytes?

-rw-r--r-- 1 tcross tcross 612856 2011-08-22 12:51 urs.org

>
>  . How many entries do you have in it, including distribution between
>   levels (i.e., how many entries of 2nd level do you have, on
>   average, per each 1st-level entry, how many 3rd-level entries per
>   each 2nd-level entry, etc.)?
>

20 leve 1 headings
Average about 6 - 10 level 2 headings in each, though there are 3
sections which contain over 50 level 2 items and a Tasks section which
has 120 TODO items (106 marked as done).

I have very few level 3 headings as I rarely get that deep. One of the
level 1 sections contains over 60 level 2 items which are include
either a timestamp or are just a timestamp.


>  . Is the slowdown the same at the beginning of the file, the end of
>   the file, and in the middle?

Yes, it appears to be

>
>  . Which commands exhibit the slowdown?  Are C-f/C-b slow?  How about
>   left and right arrows?  C-v/M-v? Up/down arrows?
>

It appears to affect all commands. Even typing is sluggish (I can get
'in front' of what is being displayed when typing quickly). Kill and
yank commands seem to be the worst, but all movement commands appear
to be affected to some degree. I get the impression the larger the
text being acted upon, the greater the slowdown.

>  . Does the slowdown go away after "M-x show-all RET"?
>

Yes it appears to.

>  . Do you have any minor modes, in addition to Org mode, turned on in
>   those buffers, and if so, which ones?  Please include any sub-modes
>   of Org in the list.

Normally I do. However, the first thing I tested was to run emacs -Q
and just start by opening the org file, so only org-mode and no other
minor modes were loaded. Problem still existed.

>
>  . Does setting bidi-paragraph-direction to `left-to-right' eliminate
>   the slowdown?

It does appear to remove the slowdown

>
> With this info, I can try reproducing the problem and looking for a
> proper solution.
>

I will try and 'clean' my org file so that all sensitive info is
removed. If after that, the problem still exists, I will send it.

Tim

Re: Slow/poor responsiveness in org files

[Eli Zaretskii]

> Date: Mon, 22 Aug 2011 16:42:56 +1000
> From: Tim Cross <theophilusx@gmail.com>
> Cc: bzg@altern.org, emacs-devel@gnu.org
> 
> >  . How large is the Org file, in bytes?
> 
> -rw-r--r-- 1 tcross tcross 612856 2011-08-22 12:51 urs.org

Strange.  I have a 3MB Org file, and I see no such terrible problems
there.  What is the speed of your CPU clock?  I have a 6-year old
single-core Pentium 4 CPU here which runs at 3GHz.

> there are 3 sections which contain over 50 level 2 items and a Tasks
> section which has 120 TODO items (106 marked as done).

Is cursor motion in those 3 sections slower than in the other ones?

> >  . Which commands exhibit the slowdown?  Are C-f/C-b slow?  How about
> >   left and right arrows?  C-v/M-v? Up/down arrows?
> >
> 
> It appears to affect all commands. Even typing is sluggish (I can get
> 'in front' of what is being displayed when typing quickly).

Is there any difference between C-f and right-arrow?  If setting
bidi-paragraph-direction to a non-nil value helps, there ought to be a
difference between these two.

> I will try and 'clean' my org file so that all sensitive info is
> removed. If after that, the problem still exists, I will send it.

Thanks.

Re: Slow/poor responsiveness in org files

[Mathieu Boespflug]

Eli Zaretskii <eliz <at> gnu.org> writes:

> 
> > Date: Mon, 22 Aug 2011 10:52:49 +1000
> > From: Tim Cross <theophilusx <at> gmail.com>
> > Cc: emacs-devel <at> gnu.org
> > 
> > SOLVED!
> > 
> > Adding the line
> > 
> > (setq bidi-display-reordering nil)
> > 
> > to my org-mode-hook has fixed the problem. Cursor movement and editing
> > operations are now usable and the delays are gone.
> 
> Please don't consider this a solution.  bidi-display-reordering should
> not slow down redisplay to a degree that makes Emacs unusable.  And
> setting bidi-display-reordering to nil means that R2L scripts cannot
> be used in Org buffers, which is clearly unacceptable.

I have experienced precisely the same behaviour in some of my org files. Here is
a link to a large (redacted) org file that exhibits this problem:

http://www.cs.mcgill.ca/~mboes/test.org

With latest emacs 24, reading this file in org-mode is noticeably slower than in
org-mode, even when all trees are folded. However that's behaviour I don't see
with emacs -Q. What I do see even with emacs -Q is very slow cursor movement and
editing after expanding the tree titled "LONG". You have to scroll down to near
the end of that tree to see what I'm talking about. Navigating subsequent trees
when the LONG tree is expanded is also slow.

>  . Does the slowdown go away after "M-x show-all RET"?

The slowdown does indeed completely disappear appear this command.

>  . Does setting bidi-paragraph-direction to `left-to-right' eliminate
>    the slowdown?

Yes.

-- Mathieu

Re: Slow/poor responsiveness in org files

[Eli Zaretskii]

> From: Mathieu Boespflug <mboes@tweag.net>
> Date: Tue, 13 Sep 2011 00:22:26 +0000 (UTC)
> 
> I have experienced precisely the same behaviour in some of my org files. Here is
> a link to a large (redacted) org file that exhibits this problem:
> 
> http://www.cs.mcgill.ca/~mboes/test.org

Thanks, I will take a look.

> With latest emacs 24, reading this file in org-mode is noticeably slower than in
> org-mode, even when all trees are folded. However that's behaviour I don't see
> with emacs -Q.

Can you try to find the customization(s) in your .emacs that cause the
slowdown not observed in "emacs -Q"?

> >  . Does setting bidi-paragraph-direction to `left-to-right' eliminate
> >    the slowdown?
> 
> Yes.

I will propose to Org mode developers a change to set
bidi-paragraph-direction automatically on all Org buffers.

Re: Slow/poor responsiveness in org files

[Torsten Wagner]

Hi Tim,


On 08/18/2011 02:56 PM, Tim Cross wrote:
> About a week or so ago, I updated emacs from bzr and saw that org 7.7
> had been merged in. Since then, I have also noticed a distinct delay
> when performing various editing operations within org files. For
> example, killing a line wiht C-k in an org mode buffer is taking about
> 4 seconds!

This might be not related to your problem but by any chance are you 
running the linum mode (displaying line numbers on the left side of the 
buffer).

I notice that this plays not well with the folding mechanisms of 
org-mode. Switching linum mode off and the pointer movement as well as 
folding/unfolding within the file becomes again very responsive and fast.

Thought this might be interesting to know...

Totti

Re: Slow/poor responsiveness in org files

[Mathieu Boespflug]

On Tue, Sep 13, 2011 at 05:59:53AM +0300, Eli Zaretskii wrote:
> > From: Mathieu Boespflug <mboes@tweag.net>
> > Date: Tue, 13 Sep 2011 00:22:26 +0000 (UTC)
> > 
> > I have experienced precisely the same behaviour in some of my org files. Here is
> > a link to a large (redacted) org file that exhibits this problem:
> > 
> > http://www.cs.mcgill.ca/~mboes/test.org
> 
> Thanks, I will take a look.
> 
> > With latest emacs 24, reading this file in org-mode is noticeably slower than in
> > org-mode, even when all trees are folded. However that's behaviour I don't see
> > with emacs -Q.
> 
> Can you try to find the customization(s) in your .emacs that cause the
> slowdown not observed in "emacs -Q"?

I believed I tracked at least one customization that causes a very
noticeable slowdown: global-hl-line-mode. On the org file linked above,
navigation is slow even with all trees folded with this minor mode
enabled.

> > >  . Does setting bidi-paragraph-direction to `left-to-right' eliminate
> > >    the slowdown?
> > 
> > Yes.
> 
> I will propose to Org mode developers a change to set
> bidi-paragraph-direction automatically on all Org buffers.

Ok. Thank you for looking into this. However, does this mean it won't be
possible to have R2L text in Org buffers?

-- Mathieu

Re: Slow/poor responsiveness in org files

[Tim Cross]

Hi Torsten,

no, not running linnum mode or anything 'special' - just org-mode.

I started cutting down my org file to try and put together a more
concise org file which Eli could work with to try and find the
problem, but darn work life has gotten in the way - hope to get back
to this today or tomorrow.

Tim


On Tue, Sep 13, 2011 at 1:20 PM, Torsten Wagner
<torsten.wagner@gmail.com> wrote:
> Hi Tim,
>
>
> On 08/18/2011 02:56 PM, Tim Cross wrote:
>>
>> About a week or so ago, I updated emacs from bzr and saw that org 7.7
>> had been merged in. Since then, I have also noticed a distinct delay
>> when performing various editing operations within org files. For
>> example, killing a line wiht C-k in an org mode buffer is taking about
>> 4 seconds!
>
> This might be not related to your problem but by any chance are you running
> the linum mode (displaying line numbers on the left side of the buffer).
>
> I notice that this plays not well with the folding mechanisms of org-mode.
> Switching linum mode off and the pointer movement as well as
> folding/unfolding within the file becomes again very responsive and fast.
>
> Thought this might be interesting to know...
>
> Totti
>



-- 
Tim Cross
Phone: 0428 212 217

Re: Slow/poor responsiveness in org files

[Eli Zaretskii]

> Date: Tue, 13 Sep 2011 00:36:25 -0400
> From: Mathieu Boespflug <mboes@tweag.net>
> Cc: emacs-devel@gnu.org
> 
> > I will propose to Org mode developers a change to set
> > bidi-paragraph-direction automatically on all Org buffers.
> 
> Ok. Thank you for looking into this. However, does this mean it won't be
> possible to have R2L text in Org buffers?

No, it doesn't mean that.  It just means the display will start at the
left window boundary, even if the item includes R2L text.  To
illustrate, you will see

* foo
* bar
* OOF
* RAB

(where "OOF" and "RAB" are R2L text typed as "FOO" and "BAR",
reordered into correct visual order), rather than

* foo
* bar
                                                                    OOF *
                                                                    RAB *

with the default (nil) setting of bidi-paragraph-direction.  I think
the latter is ugly anyway.

The variable that controls reordering is bidi-display-reordering, and
it must stay non-nil if we want to support R2L text.

The Emacs manual and the ELisp manual have more information about the
meaning of bidi-paragraph-direction, if you want to learn more.

Re: Slow/poor responsiveness in org files

[Bruno Tavernier]

Mathieu Boespflug <mboes@tweag.net> writes:

>> > With latest emacs 24, reading this file in org-mode is noticeably
>> > slower than in org-mode, even when all trees are folded. However
>> > that's behaviour I don't see with emacs -Q.
>> 
>> Can you try to find the customization(s) in your .emacs that cause
>> the slowdown not observed in "emacs -Q"?
>
> I believed I tracked at least one customization that causes a very
> noticeable slowdown: global-hl-line-mode. On the org file linked
> above, navigation is slow even with all trees folded with this minor
> mode enabled.

+1 to Mathieu's observation

After checking for the effect of several customizations,
`global-hl-line-mode' is the customization that impact most the
navigation in large org file.

-- 
Bruno

Re: Slow/poor responsiveness in org files

[Claus Klingberg]

I can second Tim's observation:

Slow scrolling and high CPU-usage in my fairly large org-mode-file,
which disappears after setting bidi-display-reordering to nil.

I was looking for an existing bug in the tracker, but couldn't find one though.

Claus



On Mon, Aug 22, 2011 at 2:52 AM, Tim Cross <theophilusx@gmail.com> wrote:
> SOLVED!
>
> Adding the line
>
> (setq bidi-display-reordering nil)
>
> to my org-mode-hook has fixed the problem. Cursor movement and editing
> operations are now usable and the delays are gone.
>
> This was with Emacs 24.0.50 revno 105525
>
> Unfortunately, I now find I have emacs generating a backtrace when I
> try to quite with the error
> void-function bidi-string-mark-left-to-right, but I think that is
> unrelated and just coincidental.
>
> Tim
>
>
> On Sat, Aug 20, 2011 at 10:53 AM, Tim Cross <theophilusx@gmail.com> wrote:
>> On Sat, Aug 20, 2011 at 10:23 AM, Bastien <bzg@altern.org> wrote:
>>> Hi Tim,
>>>
>>> Tim Cross <theophilusx@gmail.com> writes:
>>>
>>>> OK, will do.
>>>
>>> Thanks in advance!
>>>
>>>> As Bastien indicates this is a known problem, I will assume there is
>>>> an existing bug report and won't create a new one. I will post my
>>>> results back here. Given the combinations to test, this will take some
>>>> work and some time.
>>>
>>> Please first try what Antoine suggested.
>>>
>>>> One question I do have, how do I run emacs bzr trunk with org 7.4? Is
>>>> it sufficient to just ensure some 7.4 load directory is  first in the
>>>> load path?
>>>
>>> I think so.
>>>
>>>> Also, what is the url to get 7.4?
>>>
>>> http://orgmode.org/org-7.4.tar.gz
>>>
>>> Or get Org from git:
>>>
>>>  ~$ git clone git://orgmode.org/org-mode.git
>>>
>>> and checkout commit 597e2863377fb8763cf6951e3b4e777b4616300d
>>>
>>> HTH,
>>>
>>> --
>>>  Bastien
>>>
>>
>> OK, will try to do later this weekend. Was going to check the bidi
>> settings first as the changing of the default for bidi mode and the
>> merge of 7.7 occured quite close - probably within the same update for
>> me. I am a daily org user and had not noticed any performance issues
>> with 7.4.
>>
>> Need to wait until my work completes the current major system update
>> outage to get access to my large org file that I want to test with.
>> Should be able to do this tomorrow.
>>
>> Tim
>>
>> P.S. I did notice no significant performance problems with very small
>> org test files. It would seem you need to cross some size threshold
>> before you notice the performance impact.
>>
>
>

Re: Slow/poor responsiveness in org files

[Eli Zaretskii]

> Date: Tue, 13 Sep 2011 22:42:59 +0200
> From: Claus Klingberg <cjk@pobox.com>
> 
> Slow scrolling and high CPU-usage in my fairly large org-mode-file,
> which disappears after setting bidi-display-reordering to nil.

Does it also disappear when you leave bidi-display-reordering at its
default value, and instead set bidi-paragraph-direction to
`left-to-right'?

Paragraph direction in Org Mode (was: Slow/poor responsiveness in org files)

[Eli Zaretskii]

> Date: Tue, 13 Sep 2011 01:51:41 -0400
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > Date: Tue, 13 Sep 2011 00:36:25 -0400
> > From: Mathieu Boespflug <mboes@tweag.net>
> > Cc: emacs-devel@gnu.org
> > 
> > > I will propose to Org mode developers a change to set
> > > bidi-paragraph-direction automatically on all Org buffers.
> > 
> > Ok. Thank you for looking into this. However, does this mean it won't be
> > possible to have R2L text in Org buffers?
> 
> No, it doesn't mean that.  It just means the display will start at the
> left window boundary, even if the item includes R2L text.  To
> illustrate, you will see
> 
> * foo
> * bar
> * OOF
> * RAB
> 
> (where "OOF" and "RAB" are R2L text typed as "FOO" and "BAR",
> reordered into correct visual order), rather than
> 
> * foo
> * bar
>                                                                     OOF *
>                                                                     RAB *
> 
> with the default (nil) setting of bidi-paragraph-direction.  I think
> the latter is ugly anyway.

Bastien,

As followup to this thread (and other similar discussions in the
past), I propose the change below to org.el.

Let me know if you want me to commit this to the Emacs trunk or wait
for your next merge.

Thanks.


=== modified file 'lisp/org/org.el'
--- lisp/org/org.el	2011-09-02 16:38:40 +0000
+++ lisp/org/org.el	2011-09-14 15:30:49 +0000
@@ -4748,6 +4748,7 @@ The following commands are available:
     (org-set-local 'line-move-ignore-invisible t))
   (org-set-local 'outline-regexp org-outline-regexp)
   (org-set-local 'outline-level 'org-outline-level)
+  (setq bidi-paragraph-direction 'left-to-right)
   (when (and org-ellipsis
              (fboundp 'set-display-table-slot) (boundp 'buffer-display-table)
 	     (fboundp 'make-glyph-code))

Re: Slow/poor responsiveness in org files

[Eli Zaretskii]

> From: Bruno Tavernier <tavernier.bruno@gmail.com>
> Date: Tue, 13 Sep 2011 18:55:10 +0200
> 
> > I believed I tracked at least one customization that causes a very
> > noticeable slowdown: global-hl-line-mode. On the org file linked
> > above, navigation is slow even with all trees folded with this minor
> > mode enabled.
> 
> +1 to Mathieu's observation
> 
> After checking for the effect of several customizations,
> `global-hl-line-mode' is the customization that impact most the
> navigation in large org file.

Do you also see, like I do, that with `global-hl-line-mode' turned on,
navigation backwards is considerably faster than forward?  E.g., try
C-p and C-n.

Re: Slow/poor responsiveness in org files

[Bruno Tavernier]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bruno Tavernier <tavernier.bruno@gmail.com>
>> Date: Tue, 13 Sep 2011 18:55:10 +0200
>> 
>> > I believed I tracked at least one customization that causes a very
>> > noticeable slowdown: global-hl-line-mode. On the org file linked
>> > above, navigation is slow even with all trees folded with this minor
>> > mode enabled.
>> 
>> +1 to Mathieu's observation
>> 
>> After checking for the effect of several customizations,
>> `global-hl-line-mode' is the customization that impact most the
>> navigation in large org file.
>
> Do you also see, like I do, that with `global-hl-line-mode' turned on,
> navigation backwards is considerably faster than forward?  E.g., try
> C-p and C-n.

Nope. C-p and C-n appears to be equally fast.

What I notice however, is that if I unfold all the headlines displayed
on the screen, the navigation is perfectly normal.

The cursor movement only stutter when the headlines are folded (whatever
the headline level).


Finally, I tried `outline-next-visible-heading' and it turns out to works like a charm.


Hope that helps


-- 
Bruno

Re: Slow/poor responsiveness in org files

[Eli Zaretskii]

> From: Bruno Tavernier <tavernier.bruno@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 14 Sep 2011 20:00:43 +0200
> 
> What I notice however, is that if I unfold all the headlines displayed
> on the screen, the navigation is perfectly normal.
> 
> The cursor movement only stutter when the headlines are folded (whatever
> the headline level).

That is hardly surprising, if you consider what Emacs needs to do when
large portions of the buffer are not shown: it needs to find the next
visible line by scanning all the invisible ones in between.  So the
more text is folded, the slower will be the display.

> Finally, I tried `outline-next-visible-heading' and it turns out to works like a charm.

Because it doesn't try to preserve the column and support continued
lines the way next-line and previous-line do.  It simply goes to the
next heading by regexp, then checks if that heading is visible, and if
not continues to the next one.

Re: Paragraph direction in Org Mode (was: Slow/poor responsiveness in org files)

[Eli Zaretskii]

Ping!

> Date: Wed, 14 Sep 2011 18:34:21 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > Date: Tue, 13 Sep 2011 01:51:41 -0400
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: emacs-devel@gnu.org
> > 
> > > Date: Tue, 13 Sep 2011 00:36:25 -0400
> > > From: Mathieu Boespflug <mboes@tweag.net>
> > > Cc: emacs-devel@gnu.org
> > > 
> > > > I will propose to Org mode developers a change to set
> > > > bidi-paragraph-direction automatically on all Org buffers.
> > > 
> > > Ok. Thank you for looking into this. However, does this mean it won't be
> > > possible to have R2L text in Org buffers?
> > 
> > No, it doesn't mean that.  It just means the display will start at the
> > left window boundary, even if the item includes R2L text.  To
> > illustrate, you will see
> > 
> > * foo
> > * bar
> > * OOF
> > * RAB
> > 
> > (where "OOF" and "RAB" are R2L text typed as "FOO" and "BAR",
> > reordered into correct visual order), rather than
> > 
> > * foo
> > * bar
> >                                                                     OOF *
> >                                                                     RAB *
> > 
> > with the default (nil) setting of bidi-paragraph-direction.  I think
> > the latter is ugly anyway.
> 
> Bastien,
> 
> As followup to this thread (and other similar discussions in the
> past), I propose the change below to org.el.
> 
> Let me know if you want me to commit this to the Emacs trunk or wait
> for your next merge.
> 
> Thanks.
> 
> 
> === modified file 'lisp/org/org.el'
> --- lisp/org/org.el	2011-09-02 16:38:40 +0000
> +++ lisp/org/org.el	2011-09-14 15:30:49 +0000
> @@ -4748,6 +4748,7 @@ The following commands are available:
>      (org-set-local 'line-move-ignore-invisible t))
>    (org-set-local 'outline-regexp org-outline-regexp)
>    (org-set-local 'outline-level 'org-outline-level)
> +  (setq bidi-paragraph-direction 'left-to-right)
>    (when (and org-ellipsis
>               (fboundp 'set-display-table-slot) (boundp 'buffer-display-table)
>  	     (fboundp 'make-glyph-code))
> 
> 
>