* Relative performance of text-properties search functions @ 2013-05-23 12:16 Thorsten Jolitz 2013-05-23 13:10 ` Stefan Monnier 2013-05-23 15:45 ` Eli Zaretskii 0 siblings, 2 replies; 10+ messages in thread From: Thorsten Jolitz @ 2013-05-23 12:16 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relative performance of text-properties search functions 2013-05-23 12:16 Relative performance of text-properties search functions Thorsten Jolitz @ 2013-05-23 13:10 ` Stefan Monnier 2013-05-23 15:45 ` Eli Zaretskii 1 sibling, 0 replies; 10+ messages in thread From: Stefan Monnier @ 2013-05-23 13:10 UTC (permalink / raw) To: help-gnu-emacs > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relative performance of text-properties search functions 2013-05-23 12:16 Relative performance of text-properties search functions Thorsten Jolitz 2013-05-23 13:10 ` Stefan Monnier @ 2013-05-23 15:45 ` Eli Zaretskii 2013-05-24 14:10 ` Thorsten Jolitz 1 sibling, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2013-05-23 15:45 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relative performance of text-properties search functions 2013-05-23 15:45 ` Eli Zaretskii @ 2013-05-24 14:10 ` Thorsten Jolitz 2013-05-24 15:27 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Thorsten Jolitz @ 2013-05-24 14:10 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relative performance of text-properties search functions 2013-05-24 14:10 ` Thorsten Jolitz @ 2013-05-24 15:27 ` Eli Zaretskii 2013-05-24 17:26 ` Thorsten Jolitz 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2013-05-24 15:27 UTC (permalink / raw) To: help-gnu-emacs > 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relative performance of text-properties search functions 2013-05-24 15:27 ` Eli Zaretskii @ 2013-05-24 17:26 ` Thorsten Jolitz 2013-05-24 18:17 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Thorsten Jolitz @ 2013-05-24 17:26 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relative performance of text-properties search functions 2013-05-24 17:26 ` Thorsten Jolitz @ 2013-05-24 18:17 ` Eli Zaretskii 2013-05-24 18:40 ` Thorsten Jolitz 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2013-05-24 18:17 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relative performance of text-properties search functions 2013-05-24 18:17 ` Eli Zaretskii @ 2013-05-24 18:40 ` Thorsten Jolitz 2013-05-24 19:44 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Thorsten Jolitz @ 2013-05-24 18:40 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relative performance of text-properties search functions 2013-05-24 18:40 ` Thorsten Jolitz @ 2013-05-24 19:44 ` Eli Zaretskii 2013-05-24 21:14 ` Thorsten Jolitz 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2013-05-24 19:44 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relative performance of text-properties search functions 2013-05-24 19:44 ` Eli Zaretskii @ 2013-05-24 21:14 ` Thorsten Jolitz 0 siblings, 0 replies; 10+ messages in thread From: Thorsten Jolitz @ 2013-05-24 21:14 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-05-24 21:14 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-05-23 12:16 Relative performance of text-properties search functions Thorsten Jolitz 2013-05-23 13:10 ` Stefan Monnier 2013-05-23 15:45 ` Eli Zaretskii 2013-05-24 14:10 ` Thorsten Jolitz 2013-05-24 15:27 ` Eli Zaretskii 2013-05-24 17:26 ` Thorsten Jolitz 2013-05-24 18:17 ` Eli Zaretskii 2013-05-24 18:40 ` Thorsten Jolitz 2013-05-24 19:44 ` Eli Zaretskii 2013-05-24 21:14 ` Thorsten Jolitz
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).