From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: `make-overlay' very slow Date: Sat, 11 Apr 2009 08:51:09 -0400 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1239454377 3184 80.91.229.12 (11 Apr 2009 12:52:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Apr 2009 12:52:57 +0000 (UTC) Cc: acm@muc.de, schwab@linux-m68k.org, emacs-devel@gnu.org To: Werner LEMBERG Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 11 14:54:15 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 1Lscim-0006Lm-1D for ged-emacs-devel@m.gmane.org; Sat, 11 Apr 2009 14:54:08 +0200 Original-Received: from localhost ([127.0.0.1]:56151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LschN-000791-Nr for ged-emacs-devel@m.gmane.org; Sat, 11 Apr 2009 08:52:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lscg1-0006OS-5B for emacs-devel@gnu.org; Sat, 11 Apr 2009 08:51:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lscfw-0006Le-OI for emacs-devel@gnu.org; Sat, 11 Apr 2009 08:51:16 -0400 Original-Received: from [199.232.76.173] (port=51002 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lscfw-0006LP-Gf for emacs-devel@gnu.org; Sat, 11 Apr 2009 08:51:12 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:29657) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lscfu-0008I4-Sd; Sat, 11 Apr 2009 08:51:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcFAFAv4ElLd+7D/2dsb2JhbACBUsgbg3wGhRU X-IronPort-AV: E=Sophos;i="4.40,171,1238990400"; d="scan'208";a="36896410" Original-Received: from 75-119-238-195.dsl.teksavvy.com (HELO pastel.home) ([75.119.238.195]) by ironport2-out.teksavvy.com with ESMTP; 11 Apr 2009 08:51:10 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E2E6383B6; Sat, 11 Apr 2009 08:51:09 -0400 (EDT) In-Reply-To: <20090411.081150.169736792.wl@gnu.org> (Werner LEMBERG's message of "Sat, 11 Apr 2009 08:11:50 +0200 (CEST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:110213 Archived-At: > I did that (see attachment for reference), and it really works at a > reasonable speed. Good. > However, it is the completely wrong concept since > it sets the `modified' flag and stores undo information, Yes, you need to wrap the call to > add-text-properties (actually the whole loop, preferably) in something like (let ((buffer-file-name nil) ;; To prevent locking/unlocking the file. (buffer-undo-list t) (modified (buffer-modified-p))) (unwind-protect (...) (restore-modified-p modified))) We definitely need to add a macro for it. > and it fails with modes which use the `invisible' and > `intangible' properties. Since these properties are not used very often, it's probably bearable, but yes, there is a risk of interference. > So here's my item to the Emacs wishlist: Improve speed of > (make-overlay) and related functions to be as fast as setting > text properties. 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. Stefan