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: Thu, 02 Apr 2020 17:23:54 +0300 Message-ID: <83sghmx8xx.fsf@gnu.org> 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> <74f34b72-725d-2390-faea-c61daad43350@yandex.ru> <83eet7z4if.fsf@gnu.org> <838sjfyz6k.fsf@gnu.org> <7599f566-ab1d-0b79-063e-673b7fc39c8a@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="8419"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, akrl@sdf.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 02 16:24:54 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 1jK0m5-00026O-TG for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Apr 2020 16:24:53 +0200 Original-Received: from localhost ([::1]:40868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK0m4-0001Ad-W1 for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Apr 2020 10:24:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58524) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK0lQ-0000GA-U3 for emacs-devel@gnu.org; Thu, 02 Apr 2020 10:24:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jK0lP-0001O7-Vt; Thu, 02 Apr 2020 10:24:12 -0400 Original-Received: from [176.228.60.248] (port=2110 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jK0lP-0006Wj-9Z; Thu, 02 Apr 2020 10:24:11 -0400 In-Reply-To: <7599f566-ab1d-0b79-063e-673b7fc39c8a@yandex.ru> (message from Dmitry Gutov on Thu, 2 Apr 2020 00:48:20 +0300) 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:246259 Archived-At: > Cc: emacs-devel@gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca, > akrl@sdf.org > From: Dmitry Gutov > Date: Thu, 2 Apr 2020 00:48:20 +0300 > > >> No 'goto-char'. As we've established, it only affects the time taken by > >> redisplay, and I can't measure that. So I'm not profiling it either, > >> otherwise I'd be comparing apples to oranges. > > > > See the second profile below. > > Comparing both, looks like redisplay (when at eob, at least) takes > approx. the same amount of time? About 55% taken by redisplay (almost all of it due to fontification), and the other 45% are the C mode "preprocessing" when the mode is turned on in a buffer. > >> Yes. The numbers can be different, but there is definitely some up-front > >> computation there. One that's not present with e.g. js-mode. > > > > So you are saying that we should do that up-front computation just > > because CC mode currently does it? That we shouldn't try to eliminate > > such preprocessing? I don't think so. > > AFAIU CC Mode could actually eliminate it, but that would require a > significant rework of its internals. Are we still talking about integrating a completely different parsing engine into CC Mode? Then redesign is a must, right? > I'm just pointing out that apparently you didn't even notice an even > larger delay (1.7s), and were fine with it until now. I didn't "didn't notice", I actually filed several bug reports and complaints about the various slow aspects of CC mode, because the slowdown in CC mode over the years annoys me quite a lot. Some of the problems were fixed, some weren't (due to limitations of the current design, I was told). I'm not at all complacent about this. > I'm not saying that nobody should try to explore how to decrease the > delay, and what tradeoffs come with that. But for now, I think, we > should encourage our kind volunteers to just implement integration the > way TreeSitter's authors expect it. And try, on our side, to provide the > best tools for it. Then we can see how well it does or doesn't work, and > what are the biggest annoyances that the users have with it. I cannot tell the volunteers what to do and where to invest their resources. But I can provide feedback on the design ideas, based on what I know and on my experience, and I can suggest how to design and implement this to achieve good and scalable performance. In particular, I think that it is useful to know what we have tried in the past and what were the lessons we learned from that. I hope what I say is of some help, and I hope we will soon have such engine available to Emacs.