Re: find, fts: dramatical improvement of speed in find

[Askar Safin]

Hi. Thanks a lot for applying patch. I use "find" very often (always in "-L" 
mode), so its performance is important for me. So I want to continue optimizing 
it.

I found that gnulib commit 2649851d0409c3fafee7cf396d11c10892ac0e53 (2017) 
introduced a speed regression.

"find -L /home/user" on my computer with find 
79e8e03cda028c7d3134d8de63a40367eaa2f952 (2017) and gnulib 
f7eb1b99e30517fc50c130cdecec24059a1b7c4f (previous before 2649851d0409c3fafe) 
takes 7,32 s.
But same find version (79e8e03cda028c7d3134d8de63a40367eaa2f952) with gnulib 
2649851d0409c3fafee7cf396d11c10892ac0e53 takes 8,29 s.
I don't know reason, but I noticed that if I apply to regressed version (gnulib 
2649851d0409c3fafee7cf396d11c10892ac0e53) patch 
http://paste.debian.net/hidden/1ff503a8/ , then regression disappears, i. e. I 
will get normal ~7,32 s.

Also I was able to port this patch to modern find and gnulib version. Let's 
take current find master 7642d172e10a890975696d28278e5192d81afc5b and current 
gnulib master bddb8c50edc730e4ea60181a541f4fe41ba933ff (i. e. with my 
optimization from previous 
letter). If I apply patch http://paste.debian.net/hidden/845d44cf/ (this is my 
attempt to port that anti-regression patch) to this gnulib commit, then speed 
increases from 3,33 s. to 2,46 s.

Also I don't understand comment "If we're not in CWDFD mode, don't bother with 
this optimization, since the caller is not serious about performance" from 
modern gnulib sources (fts.c). What this means? When I run "find -L" (with find 
7642d172e10a890975696d28278e5192d81afc5b and gnulib 
bddb8c50edc730e4ea60181a541f4fe41ba933ff without patches from *this* letter), I 
got to that code path (I verified this by inserting fprintf there). So "find 
-L" actually gets us to that point. And I need 
performance in that use case.

==
Askar Safin
https://github.com/safinaskar