bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Askar Safin
Subject: Re: find, fts: dramatical improvement of speed in find
Date: Mon, 04 May 2020 14:39:37 +0300

Hi. It seems my previous letter was missed. Also, Paul, mailer daemon of my
mail provider mail.ru said me that it cannot deliver letters to you. You don't
want random letters or it is problem on my side?

> 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
==
Askar Safin
https://github.com/safinaskar

reply via email to

[Prev in Thread] Current Thread [Next in Thread]