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 07:14:09 +0300 Message-ID: References: <83o8sf3r7i.fsf@gnu.org> <2E218879-0F24-4A20-B210-263C8D0BEEA4@gmail.com> <838sjh2red.fsf@gnu.org> <83369o3bvb.fsf@gnu.org> <83imik1qbq.fsf@gnu.org> <835zek1kpv.fsf@gnu.org> <83v9mkz5oo.fsf@gnu.org> <83pncsym6l.fsf@gnu.org> <4a9d6bb2-458d-89b0-5389-d1f883ef24a1@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="91106"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: K-9 Mail for Android Cc: casouri@gmail.com, monnier@iro.umontreal.ca, akrl@sdf.org To: emacs-devel@gnu.org,Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 01 06:14:53 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 1jJUmC-000NbB-TN for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Apr 2020 06:14:52 +0200 Original-Received: from localhost ([::1]:46801 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJUmB-0006Vo-UK for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Apr 2020 00:14:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47739) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJUla-00065h-85 for emacs-devel@gnu.org; Wed, 01 Apr 2020 00:14:17 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jJUlZ-0005Ne-9Z; Wed, 01 Apr 2020 00:14:13 -0400 Original-Received: from [109.253.200.4] (port=38552 helo=[10.131.23.251]) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1jJUlY-0006cC-N6; Wed, 01 Apr 2020 00:14:13 -0400 In-Reply-To: <4a9d6bb2-458d-89b0-5389-d1f883ef24a1@yandex.ru> 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:246182 Archived-At: On April 1, 2020 6:49:45 AM GMT+03:00, Dmitry Gutov wr= ote: > On 01=2E04=2E2020 05:28, Eli Zaretskii wrote: > >> Cc: monnier@iro=2Eumontreal=2Eca, casouri@gmail=2Ecom, akrl@sdf=2Eorg= , > >> emacs-devel@gnu=2Eorg > >> From: Dmitry Gutov > >> Date: Tue, 31 Mar 2020 22:50:43 +0300 > >> > >>>> (benchmark 1 '(progn (find-file "src/xdisp=2Ec") (goto-char > (point-max)))) > >>>> > >>>> =3D> Elapsed time: 1=2E940401s (0=2E376140s in 6 GCs) > >>> This doesn't measure the redisplay (which happens after the above > >>> command returns)=2E > >> > >> Which means that the current state of affairs is even slower=2E > >=20 > > No, it means that whatever delay we will have with parsing the > entire > > buffer is _in_addition_ to whatever you measured=2E >=20 > Probably not=2E IIUC, most of this 1=2E2 measured delay is CC Mode doing > the=20 > preliminary parsing=2E There's no need to guess=2E Just profile this use case, and you will clea= rly see what takes most of this time=2E In general, there's no "preliminary processing" by the major mode's fontif= ication facilities except what happens as part of jit-lock, i=2Ee=2E at red= isplay time or as side effect of functions that simulate display for redisp= lay purposes=2E I'd be very surprised to see a major mode which somehow pr= eprocesses the buffer on its own in preparation for fontification=2E CC Mo= de certainly doesn't seem to do that=2E