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: bug-reference-prog-mode slows down CC Mode's scrolling by ~7% Date: Sat, 4 Sep 2021 15:32:57 +0000 Message-ID: References: <83a6kuyysv.fsf@gnu.org> <837dfwyird.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="13265"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 04 17:33:44 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 1mMXfr-0003Ia-Fg for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Sep 2021 17:33:43 +0200 Original-Received: from localhost ([::1]:59278 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMXfp-0001uo-Tz for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Sep 2021 11:33:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43514) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMXfD-00014T-KZ for emacs-devel@gnu.org; Sat, 04 Sep 2021 11:33:03 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:19509 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mMXfA-0004j7-FK for emacs-devel@gnu.org; Sat, 04 Sep 2021 11:33:03 -0400 Original-Received: (qmail 79009 invoked by uid 3782); 4 Sep 2021 15:32:58 -0000 Original-Received: from acm.muc.de (p2e5d5226.dip0.t-ipconnect.de [46.93.82.38]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 04 Sep 2021 17:32:57 +0200 Original-Received: (qmail 5455 invoked by uid 1000); 4 Sep 2021 15:32:57 -0000 Content-Disposition: inline In-Reply-To: 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=unavailable 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:273901 Archived-At: Hello, Stefan. On Sat, Sep 04, 2021 at 11:00:53 -0400, Stefan Monnier wrote: > > , it takes 27.9s. So it would seem the cost of having a jit-lock > > function returning a jit-lock-bounds structure when it's not the first > > function is high. That's using the strategy of a full refontification of > > the "extra" regions of the buffer returned in that structure. > How does it compare to the performance with the old/current > jit-lock code? That takes ~22.6s. > > Maybe that strategy is not optimal. > I think it leads to many calls to the client functions with small > regions, which for font-lock at least is not optimal indeed. > Maybe to speed things up, another option is to grow the chunk size > a bit. Maybe. An advantage of a small chunk size is that fontifying a single screen can be done with a maximum 499 bytes "inefficiency" off the end of a screen. If we were to increase jit-lock-chunk-size to, say 2000, more of the next screen would be getting fontified, perhaps wastefully. I don't know how important this is. Maybe I should try it. Indeed. With jit-lock-chunk-size at 2000, time-scroll on xdisp.c takes: (current code): 16.4s (new proposed code): 16.1s .. This speed up may well be particular to CC Mode. Let's try jit-lock-chunk-size at 8000: (current code): 15.1s (new proposed code): 15.1s .. So, yes, it would seem a larger chunk size is advantageous for CC Mode. In Emacs Lisp Mode, scrolling through jit-lock.el takes: (500): 0.195s (8000): 0.184s .. So the advantage of a bigger chunk size is less marked, here. Maybe we should consider increasing the default jit-lock-chunk-size. > Stefan -- Alan Mackenzie (Nuremberg, Germany).