From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#45898: 27.1; wedged in redisplay again Date: Tue, 14 Jun 2022 16:00:56 +0300 Message-ID: <8335g7tn5j.fsf@gnu.org> References: <46b65e3f-cf3d-a3f2-9a9a-100e58274ff6@jovi.net> <87h74wh9x7.fsf@gnus.org> <83bkv47evy.fsf@gnu.org> <87k09rbcmn.fsf@gnus.org> <83a6an5jt3.fsf@gnu.org> <8335gf5er3.fsf@gnu.org> <87leu686z4.fsf@gnus.org> <83sfoe2k0j.fsf@gnu.org> <87zgim6qtt.fsf@gnus.org> <83mtem2dc9.fsf@gnu.org> <87y1y63qmq.fsf@gnus.org> <83h74t3k5u.fsf@gnu.org> <87tu8sx569.fsf@gnus.org> <83v8t6us8t.fsf@gnu.org> <87zgiinptk.fsf@gnus.org> <83mteiufih.fsf@gnu.org> <877d5kojbo.fsf@gnus.org> <83zgigu3e0.fsf@gnu.org> <87v8t3o3nu.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12176"; mail-complaints-to="usenet@ciao.gmane.io" Cc: psainty@orcon.net.nz, Emacs-hacker2018@jovi.net, 45898@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jun 14 15:02:26 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1o16Bd-0002s5-5B for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Jun 2022 15:02:25 +0200 Original-Received: from localhost ([::1]:48782 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o16Bc-0004JX-2G for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Jun 2022 09:02:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57510) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o16BH-0004DL-B8 for bug-gnu-emacs@gnu.org; Tue, 14 Jun 2022 09:02:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39550) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o16BG-0008HB-DC for bug-gnu-emacs@gnu.org; Tue, 14 Jun 2022 09:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o16BG-00060o-A2 for bug-gnu-emacs@gnu.org; Tue, 14 Jun 2022 09:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Jun 2022 13:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45898 X-GNU-PR-Package: emacs Original-Received: via spool by 45898-submit@debbugs.gnu.org id=B45898.165521168323060 (code B ref 45898); Tue, 14 Jun 2022 13:02:02 +0000 Original-Received: (at 45898) by debbugs.gnu.org; 14 Jun 2022 13:01:23 +0000 Original-Received: from localhost ([127.0.0.1]:33445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o16Ad-0005zr-2p for submit@debbugs.gnu.org; Tue, 14 Jun 2022 09:01:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o16AU-0005zX-3W for 45898@debbugs.gnu.org; Tue, 14 Jun 2022 09:01:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35348) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o16AO-00082r-GR; Tue, 14 Jun 2022 09:01:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=zB57ooFFTXQ6E5Sx1j/CcogWDHq06HHKzgdXC7vDAZs=; b=Ng5ygvbDlHM+n0yLqW46 nqJjajT5ouz4RA1DkqPUwZB4CzOl4jW741hLo2AZDVckPL+e951u+CycCNoh+Fw6VypVzp86w2obb KCR/b+yvgydI4kPWE0DwiPDO0Lbtv0CMjZwMD4Bzcte1xTZ3Jy9x5PlWbPuW87uscNrLErSofGYFs BOyYke6QM3TRaFQWwzxZ5rT65VcCEkswZAyl+5l7ofusQlV7At6TSBYCVXauN8AKGlUrSCbfl+5G9 TvTr0w/R2aPGgDZ8lV8YoXbyWNb6vrdDEJxKgsU3AgaTbpFy4wqx7YPt2MmcN0pXNLKAKA4yMiYpa vzHCykdPEX9vJg==; Original-Received: from [87.69.77.57] (port=1281 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o16AN-0002eb-Vt; Tue, 14 Jun 2022 09:01:08 -0400 In-Reply-To: <87v8t3o3nu.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 14 Jun 2022 14:00:53 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:234496 Archived-At: > From: Lars Ingebrigtsen > Cc: Phil Sainty , Emacs-hacker2018@jovi.net, > 45898@debbugs.gnu.org > Date: Tue, 14 Jun 2022 14:00:53 +0200 > > > Yes. That idea came up while discussing this with Gerd Möllmann, btw. > > It's much simpler than measuring time (which would require > > high-resolution timing, which is much less portable and more tricky to > > get right, what with modern systems constantly adjusting their time). > > I don't think we need high resolution time here? We just need to > (coarsely) have an opinion about whether we've been spending a lot of > time... The problem is that redisplay and related code is spread all over the place, and what makes things low is not necessarily a series of consecutive calls, let alone predictable ones. So inserting calls to timing functions is problematic, and adding times instead of adding "ticks" would need high-res timing, otherwise you'd risk adding a lot of zeros. > > That's why update_redisplay_ticks accepts its first argument, instead > > of always adding 1: I thought about some potentially expensive > > operations that could be either more or less expensive than just > > processing a single character. E.g., font-lock calls regexp matching, > > so we should try to come up with some measure of its "expensiveness" > > based on...something. This will need some tuning, but all we need is > > some coarse correlation. > > Yes. I do wonder, though, whether there's going to be possible to come > up with useful tuning here -- predicting whether a regexp is "heavy" is > non trivial, to say the least. The idea is not to predict it, but to know it after the expensive operation returned. Not that doing that is trivial... Basically, any operation that is very expensive loops somewhere, so counting the loop iterations can give some idea of the "cost".