From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Reliable after-change-functions (via: Using incremental parsing in Emacs) Date: Wed, 01 Apr 2020 17:10:24 +0300 Message-ID: <83d08rz48f.fsf@gnu.org> References: <83imik1qbq.fsf@gnu.org> <835zek1kpv.fsf@gnu.org> <83v9mkz5oo.fsf@gnu.org> <83pncsym6l.fsf@gnu.org> <4a9d6bb2-458d-89b0-5389-d1f883ef24a1@yandex.ru> <20200401135237.GA6240@ACM> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="33620"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, dgutov@yandex.ru, emacs-devel@gnu.org, monnier@iro.umontreal.ca, akrl@sdf.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 01 16:11:26 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJe5V-0008cv-S4 for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Apr 2020 16:11:25 +0200 Original-Received: from localhost ([::1]:60868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJe5U-0008DG-Up for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Apr 2020 10:11:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48977) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJe4L-0006fs-Sj for emacs-devel@gnu.org; Wed, 01 Apr 2020 10:10:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jJe4L-0005uT-2x; Wed, 01 Apr 2020 10:10:13 -0400 Original-Received: from [176.228.60.248] (port=4905 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jJe4J-0003rb-A2; Wed, 01 Apr 2020 10:10:12 -0400 In-Reply-To: <20200401135237.GA6240@ACM> (message from Alan Mackenzie on Wed, 1 Apr 2020 13:52:37 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246195 Archived-At: > Date: Wed, 1 Apr 2020 13:52:37 +0000 > From: Alan Mackenzie > Cc: akrl@sdf.org, casouri@gmail.com, Dmitry Gutov , > monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > In general, there's no "preliminary processing" by the major mode's > > fontification facilities except what happens as part of jit-lock, i.e. > > at redisplay time or as side effect of functions that simulate display > > for redisplay purposes. I'd be very surprised to see a major mode > > which somehow preprocesses the buffer on its own in preparation for > > fontification. CC Mode certainly doesn't seem to do that. > > CC Mode does do this. It marks syntax-table text properties throughout > the buffer at find-file time, and keeps them valid thereafter in > before/after-change-functions. > > This doesn't seem to affect starting up performance that badly. On my > machine (a 3 yo AMD Ryzen) visiting xdisp.c (including the fontification > of the first screenful of comments) is taking 0.18s. Like I said, the profile I see is very different, and shows that most of the time is spent in redisplay-triggered font-lock. But in any case, it should be trivially obvious that avoiding to parse the entire buffer will make redisplay faster. We should try doing that instead of giving up, even if we think the current fontification machinery is slow enough to make the parsing delay not so visible. After all, we want to use these parsers to make CC Mode and friends faster, so the design and the implementation should use every trick we have up our sleeve to avoid expensive processing. Just because using buffer-substring and parsing the entire buffer up front is easy doesn't yet mean we should go for it without trying more efficient algorithms.