From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: `make-overlay' very slow Date: Tue, 14 Apr 2009 21:03:33 +0900 Message-ID: References: <20090410.235059.24212167.wl@gnu.org> <20090411.004248.247201382.wl@gnu.org> <20090411.081150.169736792.wl@gnu.org> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1239710723 17502 80.91.229.12 (14 Apr 2009 12:05:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Apr 2009 12:05:23 +0000 (UTC) Cc: acm@muc.de, schwab@linux-m68k.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 14 14:06:41 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LthO7-0004E3-1x for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2009 14:06:03 +0200 Original-Received: from localhost ([127.0.0.1]:56054 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LthMi-0001KO-Cs for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2009 08:03:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LthMe-0001KD-CU for emacs-devel@gnu.org; Tue, 14 Apr 2009 08:03:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LthMZ-0001Jv-Lh for emacs-devel@gnu.org; Tue, 14 Apr 2009 08:03:43 -0400 Original-Received: from [199.232.76.173] (port=49101 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LthMZ-0001Js-IX for emacs-devel@gnu.org; Tue, 14 Apr 2009 08:03:39 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:47121) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LthMR-0002YG-5q; Tue, 14 Apr 2009 08:03:31 -0400 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n3EC3Q1d020507; Tue, 14 Apr 2009 21:03:26 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n3EC3Pv7028877; Tue, 14 Apr 2009 21:03:25 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp2.aist.go.jp with ESMTP id n3EC3NfY014942; Tue, 14 Apr 2009 21:03:23 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1LthMT-00067B-Pu; Tue, 14 Apr 2009 21:03:33 +0900 In-reply-to: (message from Stefan Monnier on Sat, 11 Apr 2009 08:51:09 -0400) X-detected-operating-system: by monty-python.gnu.org: Solaris 9 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:110269 Archived-At: In article , Stefan Monnier writes: > Yes, that would be great. But note that it's not just `make-overlay': > every time we make a modification to the buffer, we have to update the > position of all the overlays (and markers) after point. So, yes, > a better data-structure for overlays (and markers) would be very welcome. I have not yet thought about this idea in deep but perhaps we can use one more interval tree for overlays. More radical idea, not related to overlays, is to make one interval tree for one text property; i.e. one for `face', one for `fontified'... I think it not only improves the processing speed, but also reduces the memory usage (next-property-change will get slower, but we use next-single-property-change more often). --- Kenichi Handa handa@m17n.org