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: Tue, 14 Feb 2017 11:07:13 +0100 Message-ID: <87y3x9f5m6.fsf@hochschule-trier.de> References: <87d1jylv43.fsf@fastmail.com> <87fujv64mn.fsf@hochschule-trier.de> <87fujvpkzc.fsf@fastmail.com> <87vasr5tqd.fsf@hochschule-trier.de> <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> <87zihq8nsi.fsf@hochschule-trier.de> <83inoe17l2.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1487066882 3155 195.159.176.226 (14 Feb 2017 10:08:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Feb 2017 10:08:02 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 14 11:07:56 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 1cda1b-0000GY-Tz for ged-emacs-devel@m.gmane.org; Tue, 14 Feb 2017 11:07:56 +0100 Original-Received: from localhost ([::1]:33620 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cda1f-0006KM-RA for ged-emacs-devel@m.gmane.org; Tue, 14 Feb 2017 05:07:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cda1O-0006Ix-Oc for emacs-devel@gnu.org; Tue, 14 Feb 2017 05:07:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cda1N-00004y-KY for emacs-devel@gnu.org; Tue, 14 Feb 2017 05:07:42 -0500 Original-Received: from gateway-a.fh-trier.de ([143.93.54.181]:42129) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cda1H-0008TE-TX; Tue, 14 Feb 2017 05:07:36 -0500 X-Virus-Scanned: by Amavisd-new + McAfee uvscan + ClamAV [Rechenzentrum Hochschule Trier (RZ/HT)] Original-Received: from localhost (ip5f5bdee7.dynamic.kabel-deutschland.de [95.91.222.231]) (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 7ED1E179ADA9; Tue, 14 Feb 2017 11:07:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=hochschule-trier.de; s=default; t=1487066834; bh=Flea6SYOmQ5JuQXfpFe+Gocd3NA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=d4g2ZqkBTy8koDbHinEOZ68O+CTNWtEeQUcxtX3GF9lGdI6+V5AgIJlCVOD7Vlu/r 5eOPyfoiMmCP6hHo9gaRYO/ZLcL5iOcrI09jMbzYCB8g+6+duo9rOPCXIBWnaV+ILb sotGzxjEvNnbqSjs+IafOAvPRvhWPJn6Xm0qOjos= In-Reply-To: <83inoe17l2.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Feb 2017 16:36:09 +0200") 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:212364 Archived-At: Eli Zaretskii writes: >> Do you expect redisplay performance to improve or is it your aim that it >> does not degrade ? > > It should certainly not be worse, otherwise the design and > implementation would need to be improved, IMO. Display is a very > important client of overlays, so it shouldn't suffer from refactoring. I had the idea, that this centered list intuitively sounds like a good fit for the display's requirements, i.e. usually little random access and the center can be updated relatively cheaply while scrolling. > I would be happy to know that performance gets better, of course. The > recentering of overlays, which is not a cheap operation, should no > longer be needed, for example. > It definitively is not needed. I currently trying to improve the performance of my implementation, with some success. >> BTW how do you figure out which functions need attention, >> performance-wise. > If you mean overlay-specific functions, I can name the most important > ones for you. I know which ones they are because I know what the > display engine calls in its inner loops. I guess, I figured it out. -ap