Relative performance of text-properties search functions

Relative performance of text-properties search functions

[Thorsten Jolitz]

Hi List, 

I'm just discovering Emacs text-properties, and I wonder what would be
the right thing to do (from a performance point of view) in a case where
at the end of each outline (or org-mode) headline in a buffer a
replacing display spec should be inserted, and then updated many times
afterwards (either on user demand or via a visibility-change hook):

1. use 'outline-next-visible-heading' and 'move-end-of-line' to find the
specs and then insert/modifify them?
2. use Emacs text-properties search functions to find the specs?

I would guess its (1), but would like to reassure myself by asking this
question. 

-- 
cheers,
Thorsten

Re: Relative performance of text-properties search functions

[Stefan Monnier]

> 1. use 'outline-next-visible-heading' and 'move-end-of-line' to find the
> specs and then insert/modifify them?
> 2. use Emacs text-properties search functions to find the specs?

2 is probably faster.  And it doesn't need to know anything
about outline.


        Stefan

Re: Relative performance of text-properties search functions

[Eli Zaretskii]

> From: Thorsten Jolitz <tjolitz@gmail.com>
> Date: Thu, 23 May 2013 14:16:47 +0200
> 
> the right thing to do (from a performance point of view) in a case where
> at the end of each outline (or org-mode) headline in a buffer a
> replacing display spec should be inserted, and then updated many times
> afterwards (either on user demand or via a visibility-change hook):

Beware: too many replacing display specs will slow down redisplay in
Emacs 24.1 and later.  If you have alternatives, consider them first.

Re: Relative performance of text-properties search functions

[Thorsten Jolitz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thorsten Jolitz <tjolitz@gmail.com>
>> Date: Thu, 23 May 2013 14:16:47 +0200
>> 
>> the right thing to do (from a performance point of view) in a case where
>> at the end of each outline (or org-mode) headline in a buffer a
>> replacing display spec should be inserted, and then updated many times
>> afterwards (either on user demand or via a visibility-change hook):
>
> Beware: too many replacing display specs will slow down redisplay in
> Emacs 24.1 and later.  If you have alternatives, consider them first.

I can imagine that in a .emacs with thousands of lines and hundreds of
headllines, redisplay of some headline cookies with every visibility
change will make Emacs work hard. 

-- 
cheers,
Thorsten

Re: Relative performance of text-properties search functions

[Eli Zaretskii]

> From: Thorsten Jolitz <tjolitz@gmail.com>
> Date: Fri, 24 May 2013 16:10:04 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Thorsten Jolitz <tjolitz@gmail.com>
> >> Date: Thu, 23 May 2013 14:16:47 +0200
> >> 
> >> the right thing to do (from a performance point of view) in a case where
> >> at the end of each outline (or org-mode) headline in a buffer a
> >> replacing display spec should be inserted, and then updated many times
> >> afterwards (either on user demand or via a visibility-change hook):
> >
> > Beware: too many replacing display specs will slow down redisplay in
> > Emacs 24.1 and later.  If you have alternatives, consider them first.
> 
> I can imagine that in a .emacs with thousands of lines and hundreds of
> headllines, redisplay of some headline cookies with every visibility
> change will make Emacs work hard. 

You were talking about outline or org-mode, so how is .emacs relevant?

Re: Relative performance of text-properties search functions

[Thorsten Jolitz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thorsten Jolitz <tjolitz@gmail.com>
>> Date: Fri, 24 May 2013 16:10:04 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Thorsten Jolitz <tjolitz@gmail.com>
>> >> Date: Thu, 23 May 2013 14:16:47 +0200
>> >> 
>> >> the right thing to do (from a performance point of view) in a case where
>> >> at the end of each outline (or org-mode) headline in a buffer a
>> >> replacing display spec should be inserted, and then updated many times
>> >> afterwards (either on user demand or via a visibility-change hook):
>> >
>> > Beware: too many replacing display specs will slow down redisplay in
>> > Emacs 24.1 and later.  If you have alternatives, consider them first.
>> 
>> I can imagine that in a .emacs with thousands of lines and hundreds of
>> headllines, redisplay of some headline cookies with every visibility
>> change will make Emacs work hard. 
>
> You were talking about outline or org-mode, so how is .emacs relevant?

Because my .emacs looks like this:

,----------------------------------------
| ;; * init.el --- my Emacs Init File
| ;; ** Commentary
| ;; * Prerequisites
| ;; ** Start Message and Start Time
| ;; ** Setup Parts
| ;; ** Environment
| ;; ** Loading Emacs Lisp Libraries
| ;; ** Debugging
| ;; * [Screen Input Keys Cmd Enter Exit]
| ;; ** 1 (info "(emacs)Screen")
| ;; ** 2 (info "(emacs)User Input")
| ;; ** 3 (info "(emacs)Keys")
| ;; ** 4 (info "(emacs)Commands")
| ;; ** 5 (info "(emacs)Entering Emacs")
| ;; ** 6 (info "(emacs)Exiting")
| ;; * [Basic-Edit Minibuf M-x Help]
| [...]
`----------------------------------------

with outline-minor-mode and outshine.el activated. 

For me, with outshine.el, outorg.el and navi-mode.el, my Emacs Lisp (and
other programming language) buffers have a very similar look&kfeel like
Org-mode buffers, and I do all significant editing of comment-strings in
temporary Org-mode buffers (using outorg.el or poporg.el).

This way the line between Org-mode and programming language major modes is
really blurring, I use outline functionality all the time, and I edit
text in Org-mode most of the time.

See this article for more information:

,-----------------------------------------------------------
| http://orgmode.org/worg/org-tutorials/org-outside-org.html
`-----------------------------------------------------------

and this screencast for a video demonstration:

,-------------------------------------------
| http://www.youtube.com/watch?v=nqE6YxlY0rw
`-------------------------------------------

-- 
cheers,
Thorsten

Re: Relative performance of text-properties search functions

[Eli Zaretskii]

> From: Thorsten Jolitz <tjolitz@gmail.com>
> Date: Fri, 24 May 2013 19:26:39 +0200
> 
> > You were talking about outline or org-mode, so how is .emacs relevant?
> 
> Because my .emacs looks like this:
> 
> ,----------------------------------------
> | ;; * init.el --- my Emacs Init File
> | ;; ** Commentary
> | ;; * Prerequisites
> | ;; ** Start Message and Start Time
> | ;; ** Setup Parts
> | ;; ** Environment
> | ;; ** Loading Emacs Lisp Libraries
> | ;; ** Debugging
> | ;; * [Screen Input Keys Cmd Enter Exit]
> | ;; ** 1 (info "(emacs)Screen")
> | ;; ** 2 (info "(emacs)User Input")
> | ;; ** 3 (info "(emacs)Keys")
> | ;; ** 4 (info "(emacs)Commands")
> | ;; ** 5 (info "(emacs)Entering Emacs")
> | ;; ** 6 (info "(emacs)Exiting")
> | ;; * [Basic-Edit Minibuf M-x Help]
> | [...]
> `----------------------------------------
> 
> with outline-minor-mode and outshine.el activated. 

Which is exactly the problem I was alluding to.  You may think that
when you fold the buffer text like that that Emacs has no problems
displaying that -- after all, those are just a few lines, right?  But
in fact, the way Emacs display works, it must traverse the entire text
of the portion of the buffer that corresponds to those header lines,
skipping the folded text (which has the invisible text property), and
displaying the rest.  Add to this replacing display properties, which
you say will have to change all the time (whatever that means), and
you might have annoyingly slow display operations, because replacing
display properties are treated specially by the display engine, and so
it constantly looks for them when it iterates over buffer text.

Re: Relative performance of text-properties search functions

[Thorsten Jolitz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thorsten Jolitz <tjolitz@gmail.com>
>> Date: Fri, 24 May 2013 19:26:39 +0200
>> 
>> > You were talking about outline or org-mode, so how is .emacs relevant?
>> 
>> Because my .emacs looks like this:
>> 
>> ,----------------------------------------
>> | ;; * init.el --- my Emacs Init File
>> | ;; ** Commentary
>> | ;; * Prerequisites
>> | ;; ** Start Message and Start Time
>> | ;; ** Setup Parts
>> | ;; ** Environment
>> | ;; ** Loading Emacs Lisp Libraries
>> | ;; ** Debugging
>> | ;; * [Screen Input Keys Cmd Enter Exit]
>> | ;; ** 1 (info "(emacs)Screen")
>> | ;; ** 2 (info "(emacs)User Input")
>> | ;; ** 3 (info "(emacs)Keys")
>> | ;; ** 4 (info "(emacs)Commands")
>> | ;; ** 5 (info "(emacs)Entering Emacs")
>> | ;; ** 6 (info "(emacs)Exiting")
>> | ;; * [Basic-Edit Minibuf M-x Help]
>> | [...]
>> `----------------------------------------
>> 
>> with outline-minor-mode and outshine.el activated. 
>
> Which is exactly the problem I was alluding to.  You may think that
> when you fold the buffer text like that that Emacs has no problems
> displaying that -- after all, those are just a few lines, right?  But
> in fact, the way Emacs display works, it must traverse the entire text
> of the portion of the buffer that corresponds to those header lines,
> skipping the folded text (which has the invisible text property), and
> displaying the rest.  Add to this replacing display properties, which
> you say will have to change all the time (whatever that means), and
> you might have annoyingly slow display operations, because replacing
> display properties are treated specially by the display engine, and so
> it constantly looks for them when it iterates over buffer text.

Although my init.el has some 7000 lines and lots of headlines, the usual
outline visibility and navigation commands work allright (although I
actually tend to use navi-mode for navigating in such big files), there
is no delay that makes using outline functionality uncomfortable. 

On the other hand, I already came to the conclusion that its and
illusion to have overlay cookies after all headlines that are updated
with every visibility change, that really takes the fun out of working
with such big buffers because of the frequent delays.

So its probably better to switch the cookies on when you need the info,
and switch them off otherwise.  

-- 
cheers,
Thorsten

Re: Relative performance of text-properties search functions

[Eli Zaretskii]

> From: Thorsten Jolitz <tjolitz@gmail.com>
> Date: Fri, 24 May 2013 20:40:32 +0200
> 
> Although my init.el has some 7000 lines and lots of headlines, the usual
> outline visibility and navigation commands work allright (although I
> actually tend to use navi-mode for navigating in such big files), there
> is no delay that makes using outline functionality uncomfortable. 

I know.  I worked hard to keep the delays below humanly perceptible
threshold.  I'm just saying that you should not assume this all comes
without a price.  Make your init file larger with more lines between
headlines, use too many replacing display properties, and you will
eventually see that price.

Re: Relative performance of text-properties search functions

[Thorsten Jolitz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thorsten Jolitz <tjolitz@gmail.com>
>> Date: Fri, 24 May 2013 20:40:32 +0200
>> 
>> Although my init.el has some 7000 lines and lots of headlines, the usual
>> outline visibility and navigation commands work allright (although I
>> actually tend to use navi-mode for navigating in such big files), there
>> is no delay that makes using outline functionality uncomfortable. 
>
> I know.  I worked hard to keep the delays below humanly perceptible
> threshold.  

Good job!

-- 
cheers,
Thorsten