From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: cc-mode fontification feels random Date: Fri, 11 Jun 2021 20:06:30 +0000 Message-ID: References: <83k0n2cjg5.fsf@gnu.org> <83im2lbqmv.fsf@gnu.org> <179f6e4fa40.2816.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <83fsxpbpn9.fsf@gnu.org> <83k0n09tkp.fsf@gnu.org> <837dj09p0e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37408"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, dancol@dancol.org, emacs-devel@gnu.org, Stefan Monnier , rms@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 11 22:07:09 2021 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 1lrnQq-0009XY-E4 for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Jun 2021 22:07:08 +0200 Original-Received: from localhost ([::1]:56770 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrnQp-000822-Ed for ged-emacs-devel@m.gmane-mx.org; Fri, 11 Jun 2021 16:07:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34660) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrnQL-0007Hr-72 for emacs-devel@gnu.org; Fri, 11 Jun 2021 16:06:37 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:15569 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lrnQH-0000Iv-LN for emacs-devel@gnu.org; Fri, 11 Jun 2021 16:06:36 -0400 Original-Received: (qmail 56527 invoked by uid 3782); 11 Jun 2021 20:06:31 -0000 Original-Received: from acm.muc.de (p4fe15c6b.dip0.t-ipconnect.de [79.225.92.107]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 11 Jun 2021 22:06:30 +0200 Original-Received: (qmail 7350 invoked by uid 1000); 11 Jun 2021 20:06:30 -0000 Content-Disposition: inline In-Reply-To: <837dj09p0e.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:270727 Archived-At: Hello, Eli. On Fri, Jun 11, 2021 at 22:31:45 +0300, Eli Zaretskii wrote: > > From: Stefan Monnier > > Cc: Eli Zaretskii , Alan Mackenzie , > > rudalics@gmx.at, rms@gnu.org, emacs-devel@gnu.org > > Date: Fri, 11 Jun 2021 14:42:31 -0400 [ .... ] > > Would you say that this shows the slow behaviors that bother you? > Of course. 100 msec for a single window-scroll is awfully slow. > Especially since the display code itself takes only a fraction of > that time. > > E.g. there used to be a time where I found CC-mode unusably slow in > > some cases, but these were typically while editing rather than while > > scrolling (i.e. even simple buffer modifications incurred delays > > measured in seconds). > Yes, there are other use cases, but even this simple benchmark already > shows that we have a serious problem, IMO. Compare this with Emacs 23 > or with Emacs 28 in Fundamental mode. Why do we have a problem? If the time taken to fontify a window is less than the auto-repeat time (the two times are close on a modern machine), this is surely not a problem for somebody with such a machine. It could be a problem for somebody with a slower machine, or running an unoptimised Emacs. > > FWIW, I ran this same test with `sm-c-mode` (which should handle `xdisp.c` > > about as well as CC-mode, but solves an easier problem since it doesn't > > try to handle as much of C as CC-mode does (e.g. no support for K&R, no > > highlighting of types), nor does it try to handle C++, Java, ...), and > > most of the times for it are between 0.02 and 0.04. > That is much better, but still too slow, IMO. Think: it's the time > that it takes us to fontify a single windowful, only a couple of > dozens of lines. Why does it take so long? It does a very thorough job. For example, one bug fix from many years ago that I remember involved the fontification of foo in the following: .... int bar; } foo; What face should foo have? To answer that, you've got to go back over the brace expression to see what's there. If it's struct foo { int baz; .... , we need font-lock-variable-name-face for foo. On the other hand, if we have typedef struct foo { int baz; .... , we need font-lock-type-face. Before the bug fix, foo just got variable name face. scan-lists backward over the brace expression takes time, particularly for something the size of struct frame or even bigger. -- Alan Mackenzie (Nuremberg, Germany).