From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andreas Politz Newsgroups: gmane.emacs.devel Subject: Re: Overlays as an AA-tree Date: Fri, 24 Feb 2017 09:43:16 +0100 Message-ID: <87vas07zdn.fsf@luca> References: <87d1jylv43.fsf@fastmail.com> <87d1ex4kon.fsf@hochschule-trier.de> <87d1evod6x.fsf@fastmail.com> <877f53ftab.fsf@hochschule-trier.de> <878tpiqiuc.fsf@hochschule-trier.de> <87shnppspb.fsf@hochschule-trier.de> <87o9yc9v30.fsf@hochschule-trier.de> <87a89vaes3.fsf@hochschule-trier.de> <87efz7n0g5.fsf@fastmail.com> <877f4uah6i.fsf@hochschule-trier.de> <83k28u1uyz.fsf@gnu.org> <871suxs9ad.fsf@hochschule-trier.de> <837f4pxpdc.fsf@gnu.org> <877f4lls9e.fsf@hochschule-trier.de> <838tp0q3k8.fsf@gnu.org> <87vas4owus.fsf@luca> <87r32rpfhv.fsf@luca> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1487925830 1768 195.159.176.226 (24 Feb 2017 08:43:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Feb 2017 08:43:50 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 24 09:43:45 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chBTc-0008Ks-Qj for ged-emacs-devel@m.gmane.org; Fri, 24 Feb 2017 09:43:44 +0100 Original-Received: from localhost ([::1]:35509 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chBTi-0002wU-I5 for ged-emacs-devel@m.gmane.org; Fri, 24 Feb 2017 03:43:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chBTX-0002v3-Q3 for emacs-devel@gnu.org; Fri, 24 Feb 2017 03:43:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chBTU-0003Bl-No for emacs-devel@gnu.org; Fri, 24 Feb 2017 03:43:39 -0500 Original-Received: from gateway-a.fh-trier.de ([143.93.54.181]:53061) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1chBTU-0003BQ-9S for emacs-devel@gnu.org; Fri, 24 Feb 2017 03:43:36 -0500 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier (RZ/HT)] Original-Received: from localhost (ip5f5bdeea.dynamic.kabel-deutschland.de [95.91.222.234]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: politza) by gateway-a.fh-trier.de (Postfix) with ESMTPSA id C687B179AE72; Fri, 24 Feb 2017 09:43:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de; s=default; t=1487925796; bh=Ex+UlIX0QvxSknIM5CJBdkn2UUc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=CjP64y7Yj1VpmsepPmNP8OMZxI4BnFY/xlLmRwK2U7n5k/2hZiZEo8gR1Dh55NPcQ KGhEPG24ZQSTfWcn8avLqbkgJRXbH2sk4+1tzo7nd4f+FitZDZeKLy4fAmpuGDxU46 xDTVJR55EzDFd7kpaPhYift574Z/3Jwh4rpgAeRw= In-Reply-To: (Stefan Monnier's message of "Tue, 21 Feb 2017 14:18:44 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x [fuzzy] X-Received-From: 143.93.54.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:212566 Archived-At: Stefan Monnier writes: > Is there a reason why "struct Lisp_Overlay" and "struct interval_node" > are separate? The main reason is that it can't be used for anything else, once the nodes are all Lisp_Overlay's . There are at least two other balanced trees in Emacs and maybe, at some time, there should be only one. (Also, initially I didn't need to worry about the Emacs side.) > [...] That means an overlay takes up about twice the size of a marker. > > Should we then (re)implement markers as degenerate overlays? [it's not > as simple as it sounds: contrary to overlays markers can be GC'd if not > referenced, so we'd need to add support for "weakly referenced > overlays". Furthermore markers are used to speed up byte<->char > conversions, so we'd need to replace that code accordingly. ] Could we use the end attribute as byte value ? Also, does Emacs create extra markers for this lookup or can this be called a "opportunistic optimization" ? I did some comparisons between marker and empty overlays regarding insertions and deletions. *-before and *-after insert/delete at point-min resp. -max, scatter means randomly. In each case 4096 single character were inserted/deleted. =============================================== 32K 64K ------------ ------------- 4096 edits ma ov ma ov ----------------------------------------------- insert-before 4.20 0.22 16.66 0.44 insert-after 3.28 0.12 12.96 0.20 insert-scatter 4.84 0.21 18.74 0.37 delete-before 4.09 60.32 16.16 277.75 delete-after 3.75 35.49 14.74 160.91 delete-scatter 4.02 0.36 15.64 0.86 =============================================== As you can see the delete-before/after cases are still somewhat problematic. Maybe we should think about using a single node per position combined with a list. What do you think ? -ap