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