From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: A possible way for CC Mode to resolve its sluggishness Date: Fri, 26 Apr 2019 20:11:41 +0000 Message-ID: <20190426201141.GD4720@ACM> References: <20190426193056.GC4720@ACM> <83k1fgwnkq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="162052"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 26 22:11:56 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hK7CN-000g5I-UF for ged-emacs-devel@m.gmane.org; Fri, 26 Apr 2019 22:11:56 +0200 Original-Received: from localhost ([127.0.0.1]:51502 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hK7CM-0003Qt-NG for ged-emacs-devel@m.gmane.org; Fri, 26 Apr 2019 16:11:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hK7CD-0003QB-JR for emacs-devel@gnu.org; Fri, 26 Apr 2019 16:11:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hK7CC-00034I-DT for emacs-devel@gnu.org; Fri, 26 Apr 2019 16:11:45 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:32047 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hK7CC-000313-5p for emacs-devel@gnu.org; Fri, 26 Apr 2019 16:11:44 -0400 Original-Received: (qmail 14682 invoked by uid 3782); 26 Apr 2019 20:11:42 -0000 Original-Received: from acm.muc.de (p4FE15E52.dip0.t-ipconnect.de [79.225.94.82]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 26 Apr 2019 22:11:41 +0200 Original-Received: (qmail 31294 invoked by uid 1000); 26 Apr 2019 20:11:41 -0000 Content-Disposition: inline In-Reply-To: <83k1fgwnkq.fsf@gnu.org> 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 [fuzzy] X-Received-From: 193.149.48.1 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:235968 Archived-At: Hello, Eli. On Fri, Apr 26, 2019 at 22:53:09 +0300, Eli Zaretskii wrote: > > Date: Fri, 26 Apr 2019 19:30:56 +0000 > > From: Alan Mackenzie > > (i) A CC Mode buffer will be partitioned into @dfn{syntactic cells}. > > These will be things like a section of code, a comment, a string, a raw > > string, a CPP construct .... Possibly even comment delimiters would > > have their own cells. > > (ii) Syntactic cells will be implemented by a text property, c-syntax, > > whose value will indicate the type of the cell, and possibly an > > identifier for it. Neighbouring cells will always have distinct > > c-syntax values. > Can a syntactic cell have other syntactic cells embedded in it? No. Mainly because .... > Because if it can, you cannot use text properties for that, since text > properties cannot overlap. Yes. > > Thoughts? > Why do you think this proposal will make CC Mode faster? Wouldn't > computing and updating the cells in itself be expensive? The main speed up will come from only running CC Mode's change functions occasionally, rather than at every buffer change. For most changes, there will be no need explicitly to update the cells; the text property stickiness, and so on, will do that implicitly. When there is a need, the cell boundaries will be calculated by existing algorithms, but these will get run much less frequently. For example c-fl-decl-start laboriously finds the start of the current declaration, needed as a context for accurate font-locking. The syntactic cells will cache this value, rather than it having to be continually calculated. This function is one of the main brakes to CC Mode's performance. Also, there are currently a lot of calls to c-literal-limits and friends, which use an explicit cache together with parse-partial-sexp. Being able to use text property search instead should be a speedup. -- Alan Mackenzie (Nuremberg, Germany).