From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Wed, 8 Apr 2020 02:09:13 +0000 Message-ID: <20200408020913.GA3992@ACM> References: <83sghhss8v.fsf@gnu.org> <671b5b41-663d-5ab9-f022-dc6c5ce54dd0@yandex.ru> <83r1x1sqkx.fsf@gnu.org> <83lfn9s63n.fsf@gnu.org> <83h7xvqsgc.fsf@gnu.org> <90749329-ccb1-f96e-29c0-b4ecbb81d1d4@yandex.ru> <20200407174217.GC4009@ACM> <50acd968-4459-2fab-1609-7869e1ed072a@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="54908"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, Eli Zaretskii , rrandresf@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 08 04:10:04 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 1jM0AG-000ECQ-6v for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Apr 2020 04:10:04 +0200 Original-Received: from localhost ([::1]:55186 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jM0AE-0000fi-6t for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Apr 2020 22:10:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53463) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jM09W-0000EE-Up for emacs-devel@gnu.org; Tue, 07 Apr 2020 22:09:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jM09V-0003EE-M5 for emacs-devel@gnu.org; Tue, 07 Apr 2020 22:09:18 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:63459 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1jM09V-0003BY-BH for emacs-devel@gnu.org; Tue, 07 Apr 2020 22:09:17 -0400 Original-Received: (qmail 39665 invoked by uid 3782); 8 Apr 2020 02:09:15 -0000 Original-Received: from acm.muc.de (p4FE15DB5.dip0.t-ipconnect.de [79.225.93.181]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Wed, 08 Apr 2020 04:09:13 +0200 Original-Received: (qmail 4007 invoked by uid 1000); 8 Apr 2020 02:09:13 -0000 Content-Disposition: inline In-Reply-To: <50acd968-4459-2fab-1609-7869e1ed072a@yandex.ru> 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.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:246629 Archived-At: Hello, Dmitry. On Tue, Apr 07, 2020 at 22:45:25 +0300, Dmitry Gutov wrote: > Hi Alan, > On 07.04.2020 20:42, Alan Mackenzie wrote: > >> Scenarios that are made slower if the file is large are probably caused > >> by the same architectural decisions that make (find-file "src/xdisp.c") > >> slow-ish. All those could likely be improved if CC Mode migrated to > >> using syntax-propertize-function, with its on-demand approach to parsing. > > Please would you stop saying this. It's not true, and it gets very > > wearing. The crude syntax-propertize-function mechanism would have to > > be considerably enhanced before it could support CC Mode's features. > I will shut up about it now (saying it twice it plenty), but I am pretty > confident saying that if you manage to migrate to s-p-f, file opening > time will go down. I'm sure it would. If file opening time were really a concern, a hybrid algorithm would perhaps be the best way: apply the text properties first in a lazy fashion, and thereafter treat them with care, as CC Mode currently does. But this would merely transfer the start up time to the time taken in early scrolls forward. > Performance while typing is likely to improve too, at least when the > same buffer is not shown in another window, many thousand lines later. What makes you think this? Anyway, the case you cite has to be handled well, too. > It's not a given, but I'd really like to see you try collaborating > with Stefan. At least for a prototype, to have a better idea of the > associated performance tradeoffs. He posted a preliminary patch in the > past, FWIW. > "Considerable enhancement" can also be a part of that discussion. The syntax-propertize-function mechanism works by erasing ALL syntax-table properties after a change point, then reapplying them lazily. Considering that s-t properties have an overwhelmingly local effect, this is very wasteful of processor time. Consider, for example, editing within a large C++ raw string, a common occurrence. You yourself reported as a bug sluggish performance here in mid 2016. The cause was erasing too many s-t text properties at a buffer change. I think we were talking about 1 second per typed character in the scenario you gave. There are typically lots of these properties in a raw string, in particular on " characters. Consider(2) a C++ template: excusing my C++ syntax knowledge, type in template class foo < bar, baz >= bar> , perhaps typing in the odd newline inside the template (a common occurrence), or nesting further templates inside it (also a common occurrence). Note how the parenthesis text properties are added and removed as you type. All these modification are necessary, and they are largely _before_ the point of insertion, not after it. Splatting all the properties after the point of change would be unnecessary and wasteful. > > And even then, it would be unlikely to be faster than the current CC > > Mode. > Some scenarios can become slower, that's for sure. But the more common > ones can get faster. We won't know until we try. Trying would be a _lot_ of work. How is one to handle the common example scenarios above? Well, you'd have to enhance the syntax-propertize-function with a means of determining a start position for erasing s-t props, and also a stop position. Once you do that, you're effectively doing what CC Mode currently does, so where's the speed advantage coming from? -- Alan Mackenzie (Nuremberg, Germany).