From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Manheimer Newsgroups: gmane.emacs.devel Subject: Re: outline/allout/overlay performance Date: Wed, 11 Jan 2006 19:59:28 -0500 Message-ID: <2cd46e7f0601111659x65fc0ff5ie27d69e66081c941@mail.gmail.com> References: <2cd46e7f0601091127w7f988942w33a105481ccd02e0@mail.gmail.com> <2cd46e7f0601110821x5c97c63bj25d80df70240c80e@mail.gmail.com> <2cd46e7f0601111223m4e568b56n283d038ccfff6be0@mail.gmail.com> <2cd46e7f0601111400j452ee7dexfc79b643ee3655d0@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1137027612 3322 80.91.229.2 (12 Jan 2006 01:00:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 12 Jan 2006 01:00:12 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 12 02:00:11 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ewqoz-0000nw-0H for ged-emacs-devel@m.gmane.org; Thu, 12 Jan 2006 02:00:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ewqr2-00040L-11 for ged-emacs-devel@m.gmane.org; Wed, 11 Jan 2006 20:02:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EwqqT-0003ya-Ae for emacs-devel@gnu.org; Wed, 11 Jan 2006 20:01:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EwqqR-0003xt-87 for emacs-devel@gnu.org; Wed, 11 Jan 2006 20:01:40 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EwqqQ-0003xl-4E for emacs-devel@gnu.org; Wed, 11 Jan 2006 20:01:38 -0500 Original-Received: from [66.249.92.202] (helo=uproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Ewqt8-0001tb-Ip for emacs-devel@gnu.org; Wed, 11 Jan 2006 20:04:26 -0500 Original-Received: by uproxy.gmail.com with SMTP id u2so93324uge for ; Wed, 11 Jan 2006 16:59:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LzXgHWlRX3zhpeTGwSRfiwJKLX90H3VflSvqGO0guKQQwxeoy4kRmnr+HbNdEmrFl0P8CnVhLMddCyURWcVw5Vg+T/Jq+k8pQbwwoG7ohgRPWXWprVtIVzePIRBsXETX4Bga5Gu4oSeSo8XHFG2Fsj149ntGiNmzm3J5RU2j57c= Original-Received: by 10.66.219.19 with SMTP id r19mr489772ugg; Wed, 11 Jan 2006 16:59:28 -0800 (PST) Original-Received: by 10.66.220.6 with HTTP; Wed, 11 Jan 2006 16:59:28 -0800 (PST) Original-To: Stefan Monnier In-Reply-To: Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:48946 Archived-At: it looks like i was raising a false alarm - the overlays were not the problem, and in fact there was no fragmentation of them. i made a quick consolidating function, only to discover (1) there was no improvement, and (2) actually assessing the extent of the overlays without the consolidation showed that they were not fragmenting. this lead me to suspect my environment, and i discovered that a long-line-highlighting custom package i was using (vvb-mode) was the problem - disabling it totally eliminated any delays. in fact, the side effect of this little adventure is that i'm pretty far along with the conversion to invisibility-overlays, i think the hard things are done (several niggly boundary conditions, isearch fanciness), but will need to shake out the odds and ends, and then work out the common functionality with outline-mode, as stefan and i were discussing. sorry about the false alarm! ken manheimer ken.manheimer@gmail.com On 1/11/06, Stefan Monnier wrote: > >> > i think i've surmounted the performance problem i was seeing, by > >> > better stitching together the overlays. > >> Good news. > > but maybe premature - the behaviour "came back". i will have to > > carefully implement the stitching together stuff before coming to a > > conclusion about viability. > > >> [...] > >> > these choices are hard-coded in the current `outline-flag-region', s= o > >> > i can't use it as stands. i could suggest a slightly modified versi= on > >> > which open-codes these choices so "derivative" outline modes can use= it > >> > directly while tailoring these aspects for their specific purposes. = does > >> > that seem like a reasonable way to go? > >> > >> I don't understand why outline-flag-region should have anything to do = with > >> the implementation of an isearch-open-invisible(-temporary) function, = so I'm > >> probably not understanding you well, but improving outline-flag-region= so it > > > the function is registered with the overlay, as a property - that's > > why the current outline-flag-region sets it. i want to make the > > function it registers with the overlay parameterized - eg, a mode > > local variable - to be registered if set. outline-mode's current one > > (`outline-isearch-open-invisible') will be used for outline-mode, and > > allout will have its own. other modes could, too. > > Actually, some other modes using similar functions add a few more > properties, so I think it makes sense to just add a &rest parameter to > outline-flag-region. > > As for using a buffer-local variable for outline-isearch-open-invisible, = it > assumes only one major/minor mode will use it at a time. In reveal.el > I chose to allow a reveal-toggle-invisible property on the overlay or on = the > symbol used for invisibility. So in outline.el rather than adding the > property to every single overlay, I just do > > (put 'outline 'reveal-toggle-invisible 'outline-reveal-toggle-invisible= ) > > and reveal.el finds it with > > (get (overlay-get ol 'invisible) 'reveal-toggle-invisible) > > Maybe isearch (c|sh)ould be changed in a similar way. > > >> stitches overlays together sounds like a good idea. > >> Maybe it could be made into a generic function, much like remove-overl= ays > >> and moved to subr.el. > > i'll take a look at remove-overlays, when i get to that point. > > All I was thinking is to add a function like > > (add-overlay-props FROM TO &rest PROPS) > > which either creates a new overlay with the specified props or moves > existing overlays if there's already an overlay around with the right > properties, thus trying to minimize the number of overlays in the buffer. > This said, it's probably more important to work on the C code to try and > remove the O(n) behavior. And even if it's not removed everywhere, I can= 't > think of any reason why cursor movement should suffer from this > O(n) behavior. > > > Stefan >