From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7% Date: Mon, 06 Sep 2021 09:24:29 -0400 Message-ID: References: <837dfwyird.fsf@gnu.org> <835yvgwdxb.fsf@gnu.org> <8335qkwddv.fsf@gnu.org> <83wnnwuxkj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29846"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 06 15:44:25 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 1mNEvB-0007bH-1w for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Sep 2021 15:44:25 +0200 Original-Received: from localhost ([::1]:50946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mNEv9-0005tJ-Sj for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Sep 2021 09:44:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60120) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mNEc1-0002DN-S8 for emacs-devel@gnu.org; Mon, 06 Sep 2021 09:24:37 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30007) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mNEbz-0001Nd-0r; Mon, 06 Sep 2021 09:24:36 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EA9A280903; Mon, 6 Sep 2021 09:24:34 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6DF7B807E8; Mon, 6 Sep 2021 09:24:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1630934673; bh=/nJHhfp02yqiPrgzdXRx3IiWCmNqLBTIGCZbuqlUwpk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OdIHrAKcHEhBV/4s/nG5iSLTbIg4yDfSfZWG7mxjKINlD6daUHYgeYkI9JRoHYD72 KHrgWBeCpv59vLhWZ9bvXVkHoCjJrJJn7O/Nr+hXzawNiGVPgB9ax64uJ7ZVmwEtGU scaezKBlVG/+GARdR8epnXvoHlPXXbnxueNGpGhgVg5ox9sE+7h2+cdtdE1J20Ip6E XFMlUz+4zT/aOVjvrwEU6dhJ0qpDLXtRaeW9AQAmQx46/eS6rtzGlRaTGJWiWShVnu fNowJa6dUnEWzDaclBYojxwh9NRiOg++0TWDf0XvZerW11Y3VkMEtXckoqQ3KzKp9x YupPlCi1Ni4eg== Original-Received: from milanesa (unknown [104.247.244.135]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CBBF1120340; Mon, 6 Sep 2021 09:24:29 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Mon, 6 Sep 2021 10:46:48 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:274122 Archived-At: > I think the optimal size for jit-lock-chunk-size is a little over how > much text fits in a window. That way, an entire window can be fontified > in a single chunk, minimising overhead. However, much more than that, > and the fontification is less JIT, more like fontifying large chunks of > a buffer just in case. You might be right, but really I don't know and I think no one does. E.g. Scrolling is an important case, indeed, but in the case where the user only scrolls one-screenful it might not be terribly important if we take a bit more time than strictly necessary (as long as it doesn't affect the responsiveness perceived by the user), whereas in the case where the user will scroll several screenfuls, it might be worthwhile to font-lock 2 or 3 screenfuls at a time if it increases the throughput sufficiently to keep up with the repeat rate. Also there are other very common cases where a significantly smaller amount of new text becomes visible (e.g. in response to a `delete-region`, or point movement which causes some recentering to keep point visible, maybe even with `scroll-conservatively`). In my mind, the optimal size depends on the details of the client function's cost which will likely take a form like `a + b*x` where `x` is the size of the chunk. In that case, the optimal chunk size is a tradeoff between wasted work `b*x` for too large chunks and excessive repetitions of `a` for too small chunks. Disregarding the case of invisible text, let's assume that there's only going to be one call of the client function which will result in wasted work (go past `window-end`) in a given redisplay (for a specific window). So the main downside of increasing the chunk size is the increase of latency of a single redisplay by `b*x` where `x` is the excess amount of the last chunk. As long as this `b*x` is small (at the human scale), then I think it's harmless. So maybe we should measure the "average worst case" time to fontify a chunk for different sizes (i.e. measure the average cost on a slow machine for a large buffer using a major mode where fontification is known to be expensive, e.g. using things like (c)perl-mode, or c++-mode), and then decide how much latency we're willing to pay: that might give us a "sound" basis to choose the chunk size. Stefan