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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2025, 13:32 UTC
Message-ID: <xmqqo6ud2rk9.fsf@gitster.g>
In-Reply-To: <E6A4C972-9675-47AE-B5CE-75103DB1D153@gmail.com>

Lidong Yan <yldhome2d2@gmail.com> writes:

Show 10 quoted lines

>> 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.