GNU bug report logs - #68234
[PATCH] Increase blink-matching-paren-distance by 300kb.

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Antero Mejr <antero <at> mailbox.org>
Cc: 68234 <at> debbugs.gnu.org
Subject: bug#68234: [PATCH] Increase blink-matching-paren-distance by 300kb.
Date: Thu, 4 Jan 2024 15:08:35 -0800

Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.