From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#68234: [PATCH] Increase blink-matching-paren-distance by 300kb. Date: Thu, 4 Jan 2024 15:08:35 -0800 Message-ID: References: <8734vejmaz.fsf@mailbox.org> <87v88ai77a.fsf_-_@mailbox.org> <83v889wd16.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6292"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68234@debbugs.gnu.org To: Eli Zaretskii , Antero Mejr Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 05 00:09:08 2024 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 1rLWpn-0001Rn-EH for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Jan 2024 00:09:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLWph-0000zw-0I; Thu, 04 Jan 2024 18:09:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rLWpe-0000z0-Cp for bug-gnu-emacs@gnu.org; Thu, 04 Jan 2024 18:08:58 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rLWpd-0000id-S7 for bug-gnu-emacs@gnu.org; Thu, 04 Jan 2024 18:08:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rLWph-0004V8-Ns for bug-gnu-emacs@gnu.org; Thu, 04 Jan 2024 18:09:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Jan 2024 23:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68234 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 68234-submit@debbugs.gnu.org id=B68234.170440972817282 (code B ref 68234); Thu, 04 Jan 2024 23:09:01 +0000 Original-Received: (at 68234) by debbugs.gnu.org; 4 Jan 2024 23:08:48 +0000 Original-Received: from localhost ([127.0.0.1]:55937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLWpU-0004Ug-DY for submit@debbugs.gnu.org; Thu, 04 Jan 2024 18:08:48 -0500 Original-Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]:59818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLWpS-0004UT-PV for 68234@debbugs.gnu.org; Thu, 04 Jan 2024 18:08:47 -0500 Original-Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2cd0db24e03so12582871fa.3 for <68234@debbugs.gnu.org>; Thu, 04 Jan 2024 15:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704409717; x=1705014517; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=MpAQubPD92mPU1M0MEivPqGUPU3YJZu3kaMXyAvTu+E=; b=YNSzHdCFnmG1CM4v0DgQgVsjrk8Y82DnJdaVT8xJf9lSfiK4AWHETBzwHVCb05E4gW KD84aTT+bu3YTxV74QGCtz2JRobhGeovXSkf48rxtFv82/S8fFXlKwWva2nsu2c4V6lm jgsNl1OYxqoRXDDlhVM2PFgGR9+YvLnE4pWKBMNL4rsgj6Tsl0wUj88NzgKjk+1oXDMx 08VTXJ9+L0+tjwiGbZ2jhVDh0bQMJ4lz1FuPwrcRJGjDgjKJJe3QJsShhWTlbYlLu7uG 1UwlgVlw7qB1OG1b6SJP7svFM1LkSLdpBnA9j11ZYjbdXhpTGvb4bWAV24EY16oDWnnN um6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704409717; x=1705014517; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MpAQubPD92mPU1M0MEivPqGUPU3YJZu3kaMXyAvTu+E=; b=VRjxrvRCtt+XT7lhwG25qDDn2DQ5C4ri+na5pyR+1p5bTfv3JL2TZJL7XTYRxbYVmC AZKaGivd7xpAO/mz0tY3Nnz7AHpRnd802hJEZ4ReBZgsbdBEpkK5MWIoukouoEJUntlP Mgr1Yrk6bSRGDNMb/ZGxakV0JWzv9XS/bBcHyyGASiNCJhJmS3ffO7yAInulaC9wDf/q z8ZdNaCWAS+RJKVtv43ftVKaPDkgTw4yopMKnYfJbSeFOqHbhTSm6PXW+dLPDjZ9Ug0R hyNfO32LDh33Rvz1edLfKLv2Ha8DFozKt+ciknhu64+1VRs0Dfhg77EA5H/kvBxxBhpL GdlQ== X-Gm-Message-State: AOJu0Yy9A5Ig8Lvy7/HRL07Urkhcy2JjkdZ31d3T69wU6b5Hj96NdSak iZkoabGw/UZQtDMG5zthlifdGORRF4RZLH15Y24= X-Google-Smtp-Source: AGHT+IHnZYEU9RFNbiGUGlFhXkWgtr8tDA3/Oxlh1ru/41LM1D2J4uTwkqjoSR9Z/BpBIDlWGDb1XhhCd/gfX+2rh/c= X-Received: by 2002:a2e:9818:0:b0:2cc:f02c:c96c with SMTP id a24-20020a2e9818000000b002ccf02cc96cmr368283ljj.77.1704409716523; Thu, 04 Jan 2024 15:08:36 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 4 Jan 2024 15:08:35 -0800 In-Reply-To: <83v889wd16.fsf@gnu.org> 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:277340 Archived-At: Eli Zaretskii writes: >> -(defcustom blink-matching-paren-distance (* 100 1024) >> +(defcustom blink-matching-paren-distance (* 400 1024) >> "If non-nil, maximum distance to search backwards for matching open-paren. >> If nil, search stops at the beginning of the accessible portion of the buffer." >> - :version "23.2" ; 25->100k >> + :version "23.2" ; 25->100k->400k >> :type '(choice (const nil) integer) >> :group 'paren-blinking) > > Do people feel okay with increasing this value by a factor of 4? This > blinking is supposed to be very fast, so if this will slow down > display, it's not TRT. I benchmarked this on my old ~2013 GNU/Linux machine using: (progn (goto-char (point-max)) (insert "}") (let ((minibuffer-message-timeout 0) (blink-matching-delay 0) (repeat 20) fst) (dolist (distance (number-sequence 100 1000 100)) (let* ((blink-matching-paren-distance (* distance 1024)) (time (car (benchmark-run repeat (blink-matching-open))))) (message "distance %-4dKB takes %-.3fs (x%.1f)" distance (/ time repeat) (/ time (setq fst (or fst time)))))))) In src/lisp.h (176 KB/5607 lines), I get: distance 100 KB takes 0.011s (x1.0) distance 200 KB takes 0.015s (x1.3) distance 300 KB takes 0.015s (x1.3) distance 400 KB takes 0.015s (x1.3) * [etc.] In src/xterm.c (945 KB/32842 lines), I get: distance 100 KB takes 0.010s (x1.0) distance 200 KB takes 0.017s (x1.6) distance 300 KB takes 0.025s (x2.4) distance 400 KB takes 0.034s (x3.3) * distance 500 KB takes 0.042s (x4.1) distance 600 KB takes 0.051s (x5.0) distance 700 KB takes 0.060s (x5.8) distance 800 KB takes 0.068s (x6.7) distance 900 KB takes 0.078s (x7.6) distance 1000KB takes 0.079s (x7.7) I also tried this in a ridiculous 23 MB header file that I found in the Linux kernel tree, which my Emacs opens in fundamental-mode: distance 100 KB takes 0.005s (x1.0) distance 200 KB takes 0.005s (x1.0) distance 300 KB takes 0.008s (x1.5) distance 400 KB takes 0.010s (x2.0) * distance 500 KB takes 0.013s (x2.5) distance 600 KB takes 0.015s (x3.1) distance 700 KB takes 0.018s (x3.6) distance 800 KB takes 0.020s (x4.1) distance 900 KB takes 0.023s (x4.6) distance 1000KB takes 0.025s (x5.1) Humans can't perceive delays smaller than 100 ms, so my conclusion here is that setting this to 400 KB shouldn't normally lead to any noticeable slowdown. On the other hand, we get improved correctness, which sounds like a win. We also have to take into account the compound effect with other features (such as third-party packages) that also may be slowing things down. However, this should only affect typing closing parens, so maybe correctness could still be considered more important. Of course, we could also double (instead of quadruple) this number, and get most of the benefits still. Eli, do you have any preference? Note finally that the above examined files are unusually large (as is often the case in our tree). PS. Out of interest, in a recent copy of the Linux kernel the median *.[ch] file size is ~5 KB. In emacs/src, we have instead a median *.[ch] file size of ~21KB.