Re: [PATCH v2] name-hash: don't add sparse directories in threaded lazy init

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

 



Hey Junio,

With respect to messaging I more or less copy-pasted Derricks message
from the original commit for non-threaded init: please check the
referenced commit. Let me know if another wording is needed/preferred.

>  Also, can we have performance numbers in the
proposed log message as well, or is the improvement too small to
measure?

In their current form benchmarks do not show major improvements
outside of special casing I mentioned in my previous message
(existence of files/objects outside of sparse cones in special VFS
setups). So, for the general audience this indeed can be treated as a
correctness fix.

On Wed, May 21, 2025 at 10:32 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> "Alex Mironov via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
> > From: Alex Mironov <alexandrfox@xxxxxxxxx>
> >
> > Ensure that logic added in 5f11669586 (name-hash: don't add directories
> > to name_hash, 2021-04-12) also applies in multithreaded hashtable init
> > path.
> >
> > Sparse directory entries represent a directory that is outside the
> > sparse-checkout definition. These are not paths to blobs, so should not
> > be added to the name_hash table as they must never be queried.
>
> The second paragraph sounds as if this is a correctness fix,
> i.e. "should not be added" hints that we would see a wrong result
> returned from the hashmap if you added these entries to the
> name_hash.  If this is a performance-only fix, that should be more
> clearly stated.  Also, can we have performance numbers in the
> proposed log message as well, or is the improvement too small to
> measure?
>
> Thanks.



-- 
Best,
Alex Mironov





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux