Re: Perf bug: rev-list w/ 2+ paths relatively slow with commit-graph

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

 



Kai Koponen <kaikoponen@xxxxxxxxxx> writes:

> I see, more of a perf FR than a bug then.
> I don't have much expertise here, but on the surface of it, it doesn't
> seem to me like there would be any reason the algorithm couldn't check
> each path's bloom filter in turn while searching, other than that this
> would be a large and annoying change.

It looks like that the necessary changes are probably fairly well
isolated to two functions, i.e., prepare_to_use_bloom_filter() and
forbid_bloom_filters().  Right now, for a pathspec that has one
element "dir/file", the code uses two bloom keys for "dir" and
"dir/file", but if we have "dir1/file1" as well, then it does look
like a matter of using two more (and the bloom_keys[] array is
designed to be variable length).

But those who have more intimate knowledge in the area than I do may
point out what is missing in my "it looks like" gut feeling.




[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