bug#64735: 29.0.92; find invocations are ~15x slower because of ignores

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> And if this is about testing REGEXP for being a trivial one, adding
> such a test to the existing code is trivial, and hardly justifies an
> objection to what I wrote.

I was replying to your interpretations on why I included "no-regexp"
test.

I agree that we should not use this test as comparison with GNU find.
But I also wanted to say that adding the trivial REGEXP test will be
useful. Especially because it is easy. Should I prepare a patch?

>> Isn't `file-name-all-completions' more limited and cannot accept
>> arbitrary regexp?
>
> No, see completion-regexp-list.

That would be equivalent to forcing `include-directories' being t.

In any case, even if we ignore INCLUDE-DIRECTORIES, there is no gain:

(my-bench 10 "/usr/src/linux/" "")

(("built-in non-recursive no filename handler alist" . "Elapsed time: 5.780714s 
(4.352086s in 6 GCs)")
 ("built-in non-recursive no filename handler alist + completion-regexp-list" . 
"Elapsed time: 5.739315s (4.359772s in 6 GCs)"))

 (let ((gc-cons-threshold most-positive-fixnum))
   (my-bench 10 "/usr/src/linux/" ""))
   
(("built-in non-recursive no filename handler alist" . "Elapsed time: 
1.267828s")
("built-in non-recursive no filename handler alist + completion-regexp-list" . 
"Elapsed time: 1.275656s"))

In the test, I removed all the `string-match' calls and instead let-bound 
(completion-regexp-list (list regexp))

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>