Re: master 695f679: Remove ; ; ; ###tramp-autoload cookie from Tramp defcustoms (Bug#47063)

[Lars Ingebrigtsen <larsi@gnus.org>]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>   e w w - TAB C-a C-k RET
>   bench-pred-expensive 1.080096 30 0.413564
>   bench-pred-expensive 1.078444 30 0.413685
>   bench-pred-expensive 1.077938 30 0.414732
>   bench-pred-none      1.003878 30 0.416143
>   bench-pred-none      0.987872 30 0.413814
>   bench-pred-none      0.991742 30 0.416257
>   bench-pred-old       0.889184 25 0.343545
>   bench-pred-old       0.889369 25 0.344027
>   bench-pred-old       0.885496 25 0.343227
>   bench-pred-new       0.901361 25 0.345625
>   bench-pred-new       0.887233 25 0.344885
>   bench-pred-new       0.889201 25 0.344515
>
> Where bench-pred-new extends bench-pred-old with the suggested
> condition-case-unless-debug in the "tight" loop.

Hm...  I'm not quite sure I understand these benchmarks.  There are no
completion predicates for any eww-* symbols, I think?  So there
shouldn't be any differences here at all, if I read the patch correctly.

What I was wondering was -- if (at some point in the future) we have,
say, 2K symbols with a completion predicate -- would putting that
condition-case inside the loop make things slower or not?  My gut
feeling says that it's probably not an issue (so we should just go ahead
and do it), but it'd be nice to know...

I just did a simple comparison of

(defun foo1 ()
  (+ 1 2))

(defun foo2 ()
  (condition-case ()
      (+ 1 2)
    (error nil)))

and the latter is 25% slower...  But:

(benchmark-run 10000000 (foo2))
=> (0.42124799 0 0.0)

So ten million condition-cases doesn't take a lot of time, so it's fine
to have it in the completion loop here.

> Of course this use case isn't as critical/irreversible as
> post-command-hook or process filters/sentinels, but the general notion
> is similar: it would be nice if code errors didn't bork M-x completion.

Yup; true.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no