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

[Junio C Hamano <gitster@pobox.com>]

Lidong Yan <yldhome2d2@gmail.com> writes:

>> 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).
>
> I believe the issue here is that revs->bloom_keys[] represents an
> AND condition, whereas what we actually want is an OR.

Yeah, you're right. bloom.c:bloom_filter_contains() is called repeatedly
by check_maybe_different_in_bloom_filter() to see if all the bloom_keys[]
appear to judge if it is possible that the path is changed by the commit.

So if we wanted to extend in the way we discussed in the message you
are respoinding to, revs->bloom_keys[] needs to become an array of
bloom_keys[], one for each literal pathspec element, and then we can
extend check_maybe_different_in_bloom_filter() to run the current
logic for each literal pathspec element, and combine the results by
ORing them.  The way revision.c:release_revisions() releases the
bloom keys also need to be updated.