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: Sun, 13 Mar 2016 17:59:22 +0000 Message-ID: <20160313175922.GE1871@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1457891834 9137 80.91.229.3 (13 Mar 2016 17:57:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Mar 2016 17:57:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 13 18:57:01 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 1afAGC-0002Rg-CO for ged-emacs-devel@m.gmane.org; Sun, 13 Mar 2016 18:57:00 +0100 Original-Received: from localhost ([::1]:37016 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afAGB-0004Zm-PG for ged-emacs-devel@m.gmane.org; Sun, 13 Mar 2016 13:56:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afAFy-0004ZS-UT for emacs-devel@gnu.org; Sun, 13 Mar 2016 13:56:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afAFu-0004lx-Rs for emacs-devel@gnu.org; Sun, 13 Mar 2016 13:56:46 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:39538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afAFu-0004lm-Iu for emacs-devel@gnu.org; Sun, 13 Mar 2016 13:56:42 -0400 Original-Received: (qmail 19120 invoked by uid 3782); 13 Mar 2016 17:56:41 -0000 Original-Received: from acm.muc.de (p5B146B5E.dip0.t-ipconnect.de [91.20.107.94]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 13 Mar 2016 18:56:40 +0100 Original-Received: (qmail 1217 invoked by uid 1000); 13 Mar 2016 17:59:22 -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:201620 Archived-At: Hello, Dmitry. On Sun, Mar 13, 2016 at 12:16:38AM +0200, Dmitry Gutov wrote: > On 03/12/2016 11:58 PM, Alan Mackenzie wrote: > > In a large buffer, this involves scanning on average 10,000 characters > > with parse-partial-sexp. This is not what I meant by "fast". > That severely depends on your usage. Have you tried it? Have now, yes. > First, if your calls to syntax-ppss are performed with non-decreasing > argument (or it decreases rarely), the cache in syntax-ppss-last will > help a lot. OK, I'd overlooked that. > Second, I'm sure you can decrease syntax-ppss-max-span, if your language > is expensive to parse. I would think the speed of parse-partial-sexp is pretty much constant, independent of the language. > Third, I *would* call it fast. Examples: [ .... ] > (parse-partial-sexp 15082 25082) takes ~0.0005sec. OK. [ .... ] > > What I had in mind looks more like (note the recent renaming of > > `comment-depth' to `literal-cache'): > > (setq lc (get-text-property (point) 'literal-cache)) > > (when (not (equal lc '(0 . 0))) > > (setq start (previous-single-property-change (point) 'literal-cache)) > > (goto-char start) > > ;; Move back over opening delimiter(s). > > ) > Yes, it's probably faster on average, by some constant multiplier. It will be much faster. The only looping involved is over the levels of an optimised binary tree (the text property intervals), not linearly over 10k characters. By the time syntax-ppss has finished consing down its cache list, the text property stuff would be done. > But it comes with a set of drawbacks that has already been brought up > in the discussions. That set has one member: the partial overlap in functionality with syntax-ppss. No intrinsic drawbacks have yet been pointed out. But you do so below (thanks!). > Since the text property approach exchanges memory for performance, I've counted the intervals on xdisp.c. Fully fontified, xdisp on master, there are 55274 intervals with ~442192 conses (That's estimating 2 conses per symbol/property pair on the interval's plist). 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. -- Alan Mackenzie (Nuremberg, Germany).