Re: [bug #58197] "find" fails to optimize "-path /usr/foo -o -path /usr/bar" to "-regex '/usr/\(foo\|bar\)'"

> On 19 Jul 2023, at 11:52 PM, Spencer Baugh <[email protected]> wrote:
> 
> Follow-up Comment #3, bug #58197 (project findutils):
> 
> One use case is GNU Emacs which heavily uses find, for example in M-x rgrep. 
> Emacs often constructs find commands which look like this by default:
> 
> find -H . \( -path \*/SCCS/\* -o -path \*/RCS/\* -o -path \*/CVS/\* -o -path
> \*/MCVS/\* -o -path \*/.src/\* -o -path \*/.svn/\* -o -path \*/.git/\* -o
> -path \*/.hg/\* -o -path \*/.bzr/\* -o -path \*/_MTN/\* -o -path \*/_darcs/\*
> -o -path \*/\{arch\}/\* -o -path \*/.\#\* -o -path \*.o -o -path \*\~ -o -path
> \*.bin -o -path \*.lbin -o -path \*.so -o -path \*.a -o -path \*.ln -o -path
> \*.blg -o -path \*.bbl -o -path \*.elc -o -path \*.lof -o -path \*.glo -o
> -path \*.idx -o -path \*.lot -o -path \*.fmt -o -path \*.tfm -o -path \*.class
> -o -path \*.fas -o -path \*.lib -o -path \*.mem -o -path \*.x86f -o -path
> \*.sparcf -o -path \*.dfsl -o -path \*.pfsl -o -path \*.d64fsl -o -path
> \*.p64fsl -o -path \*.lx64fsl -o -path \*.lx32fsl -o -path \*.dx64fsl -o -path
> \*.dx32fsl -o -path \*.fx64fsl -o -path \*.fx32fsl -o -path \*.sx64fsl -o
> -path \*.sx32fsl -o -path \*.wx64fsl -o -path \*.wx32fsl -o -path \*.fasl -o
> -path \*.ufsl -o -path \*.fsl -o -path \*.dxl -o -path \*.lo -o -path \*.la -o
> -path \*.gmo -o -path \*.mo -o -path \*.toc -o -path \*.aux -o -path \*.cp -o
> -path \*.fn -o -path \*.ky -o -path \*.pg -o -path \*.tp -o -path \*.vr -o
> -path \*.cps -o -path \*.fns -o -path \*.kys -o -path \*.pgs -o -path \*.tps
> -o -path \*.vrs -o -path \*.pyc -o -path \*.pyo \) -prune -o  -type f 
> -print0
> 
> That is, it lists a bunch of file extensions to ignore (from
> grep-find-ignored-files) and passes them to find.
> 
> Because find does not optimize this, the list of file extensions completely
> dominates the cost of the find execution; on my system, running a find over a
> particularly common directory, going from the full set of ignores to just one
> takes the find execution time from:
> 
> real    0m7.807s
> user    0m7.505s
> sys    0m0.359s
> 
> to:
> 
> real    0m0.491s
> user    0m0.221s
> sys    0m0.293s
> 
> Could you reconsider optimizing this case?
> 
> If not, how should Emacs be invoking find instead?  Should we optimize this
> into a single regex before passing it to find?  That is a bit worse user
> experience, because we provide the ability to edit the find invocation, but it
> may be worth it for speed improvements.
> 
> 
> 
>    _______________________________________________________
> 
> Reply to this item at:
> 
>  <https://savannah.gnu.org/bugs/?58197>
> 
> _______________________________________________
> Message sent via Savannah
> https://savannah.gnu.org/
> 
> 

What if you use “-regex” with all the expressions joined in one with the OR operator?

Regards,
Nikolaos Chatzikonstantinou