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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: antero <at> mailbox.org, 68234 <at> debbugs.gnu.org
Subject: bug#68234: [PATCH] Increase blink-matching-paren-distance by 300kb.
Date: Fri, 05 Jan 2024 09:49:00 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 4 Jan 2024 15:08:35 -0800
> Cc: 68234 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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)

Based on these times, I don't recommend raising the threshold above
200K.

> 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:

I don't think Fundamental mode is relevant: everything is
lightning-fast there.  I would be interested in modes like Python,
though, if this is relevant for them.

> Humans can't perceive delays smaller than 100 ms

That's not true: 50 ms is already perceptible.  Moreover, this
particular time is an add-on to the redisplay time after cursor
movement, so adding even a few tens of msec could easily pass the
perception threshold.  And finally, some people, including on this
list, use machines older and much slower than those from 10 years ago.

> Of course, we could also double (instead of quadruple) this number, and
> get most of the benefits still.
> 
> Eli, do you have any preference?

I think we can at most double it at this time.  This is a defcustom,
so people can always increase it in their local configurations if they
have much faster machines and need routinely to cope with such large
parenthetical expressions.

> Note finally that the above examined files are unusually large (as is
> often the case in our tree).

What matters is not the size of the file, but the size of a
parenthetical expression.

Previous Next

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