From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'. Date: Mon, 14 Mar 2016 12:51:37 +0000 Message-ID: <20160314125137.GD1894@acm.fritz.box> References: <20160308183010.GB6269@acm.fritz.box> <20160309174816.GE3948@acm.fritz.box> <56E0805F.3050804@gmx.at> <20160312170839.GE2572@acm.fritz.box> <20160312215839.GC10781@acm.fritz.box> <20160313175922.GE1871@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457959770 27948 80.91.229.3 (14 Mar 2016 12:49:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Mar 2016 12:49:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 14 13:49:23 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1afRw1-0001H1-5B for ged-emacs-devel@m.gmane.org; Mon, 14 Mar 2016 13:49:21 +0100 Original-Received: from localhost ([::1]:40824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afRw0-0002tk-Jh for ged-emacs-devel@m.gmane.org; Mon, 14 Mar 2016 08:49:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afRvk-0002td-6z for emacs-devel@gnu.org; Mon, 14 Mar 2016 08:49:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afRve-0007sJ-Bn for emacs-devel@gnu.org; Mon, 14 Mar 2016 08:49:04 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:25541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afRve-0007s5-2j for emacs-devel@gnu.org; Mon, 14 Mar 2016 08:48:58 -0400 Original-Received: (qmail 79065 invoked by uid 3782); 14 Mar 2016 12:48:56 -0000 Original-Received: from acm.muc.de (p579E8DE5.dip0.t-ipconnect.de [87.158.141.229]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 14 Mar 2016 13:48:55 +0100 Original-Received: (qmail 2991 invoked by uid 1000); 14 Mar 2016 12:51:37 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201692 Archived-At: Hello, Stefan. On Sun, Mar 13, 2016 at 06:49:53PM -0400, Stefan Monnier wrote: > > In branch comment-cache, on a fully fontified, and fully cached xdisp.c > > buffer, there are 55786 intervals with ~557860 conses, that's an extra > > 512 intervals, or less than 1%. There are an extra ~115668 conses, > > about an extra 25%. I'll admit this is a drawback. > There's also the extra cost of applying all those text-properties .... I've just timed this over xdisp.c. A parse-partial-sexp from (point-min) to (point-max) took 0.031s. A further scan, applying the `literal-cache' properties, took 0.054s. That's 0.023s on a 1 MByte buffer. That's not too serious. > .... plus the cost of slowing down application of other > text-properties (since every time we modify intervals, we have to play > with the lists of properties of the intervals involved), plus the cost > of slowing down all lookups of other text-properties. I imagine the cost of consing over three properties rather than just two in an interval's plist will be negligible. The impact of the extra intervals will also be small. Heck, we use two whole properties for font-locking, and nobody notices any slow downs that causes. One implementation possibility would be to put `literal-cache' properties on a distinct interval tree from text properties, thus speeding up both, but it doesn't seem needed as yet. > These were some of the reasons which made me choose a separate table for > syntax-ppss rather than using text-properties. OK. > This said, I don't think it matters much. FWIW, syntax-ppss uses a very > naive singly-linked list for the simple reason that I decided to "first > get something working", and I just haven't found a need to go back and > optimize this data-structure (which could be turned into a tree or even > an array, in case it mattered). > Another motivation to go with a separate table was that I figured > I would then be able to more easily manipulate the cache, e.g. in case > I wanted to keep several versions of the cache at the same time (e.g. one > version per syntax-table value being used, or one version per value of > `point-min'). But there again, I haven't had the need to go back and > add that kind of functionality yet. > IOW, I don't think the exact representation chosen matters much. > What I do think is a pity in your implementation (thinking of it as > a potential replacement for syntax-ppss) is that it has to do all the > hard work of computing a full "parse-partial-sexp state" (aka PPSS) and > then throws away the parenthesis part of the state to only keep the > string/comment part, making it unable to provide as much info as > syntax-ppss does, even though it had to work just as hard for it. Retaining all the information would be much harder and much more resource intensive. That why I said the comment-cache implementation is for a different purpose from syntax-ppss. syntax-ppss throws away a lot more information that comment-cache does - it retains a parse state only every 20,000 characters, discarding everything else between those points. This makes its cache unsuitable for using the way I'd like to in back_comment. > Stefan -- Alan Mackenzie (Nuremberg, Germany).