From: Junio C Hamano <gitster@pobox.com>
To: Toon Claes <toon@iotcl.com>
Cc: git@vger.kernel.org, Gusted <gusted@codeberg.org>,
Jeff King <peff@peff.net>
Subject: Re: [PATCH 2/4] revision: expose check for paths maybe changed in Bloom filter
Date: Fri, 17 Jul 2026 13:47:03 -0700 [thread overview]
Message-ID: <xmqqwlut1gzc.fsf@gitster.g> (raw)
In-Reply-To: <20260717-toon-speed-up-last-modified-v1-2-410418f18614@iotcl.com> (Toon Claes's message of "Fri, 17 Jul 2026 17:47:00 +0200")
Toon Claes <toon@iotcl.com> writes:
> @@ -748,26 +748,20 @@ static int check_maybe_different_in_bloom_filter(struct rev_info *revs,
> struct commit *commit)
> {
> struct bloom_filter *filter;
> - int result = 0;
> -
> - if (!revs->bloom_keyvecs_nr)
> - return -1;
> + int result;
>
> if (commit_graph_generation(commit) == GENERATION_NUMBER_INFINITY)
> return -1;
>
> filter = get_bloom_filter(revs->repo, commit);
> -
> if (!filter) {
> count_bloom_filter_not_present++;
> return -1;
> }
>
> - for (size_t nr = 0; !result && nr < revs->bloom_keyvecs_nr; nr++) {
> - result = bloom_filter_contains_vec(filter,
> - revs->bloom_keyvecs[nr],
> - revs->bloom_filter_settings);
> - }
> + result = revs_maybe_changed_in_bloom(revs, filter);
> + if (result < 0)
> + return result;
>
> if (result)
> count_bloom_filter_maybe++;
Doesn't this change skew the stats?
In today's code, revs->bloom_keyvecs_nr == 0 results in an early
return, without touching count_bloom_filter_not_present. In the
updated code, we would not notice revs->bloom_keyvecs_nr being zero
and call get_bloom_filter() first. If that yields NULL, we increment
_not_present variable.
Also an error return -1 from bloom_filter_contains_vec() breaks the
loop in today's code, increments count_bloom_filter_maybe (even
though the result is -1, not positive) and returns. In updated
code, an error return would return from this function but neither
_maybe nor _definitely_not is incremented.
It could be that these two are intended "while at it we fix it too"
improvements, but then they deserve to be mentioned in the proposed
log message. Personally, I think the first one that increments the
_not_present statistics when keyvecs is empty a bug, though.
> @@ -777,6 +771,23 @@ static int check_maybe_different_in_bloom_filter(struct rev_info *revs,
> return result;
> }
>
> +int revs_maybe_changed_in_bloom(struct rev_info *revs,
> + struct bloom_filter *filter)
> +{
> + int result = 0;
> +
> + if (!revs->bloom_keyvecs_nr)
> + return -1;
> +
> + for (size_t nr = 0; !result && nr < revs->bloom_keyvecs_nr; nr++) {
> + result = bloom_filter_contains_vec(filter,
> + revs->bloom_keyvecs[nr],
> + revs->bloom_filter_settings);
> + }
> +
> + return result;
> +}
This is inherited from the original, but I think it would be easier
to follow if it were written like this:
for (size_t nr = 0; nr < revs->bloom_keyvecs_nr; nr++) {
if ((result = bloom_filter_contains_vec(filter,
revs->bloom_keyvecs[nr],
revs->bloom_filter_settings)))
return result;
}
return 0;
next prev parent reply other threads:[~2026-07-17 20:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 15:46 [PATCH 0/4] last-modified: use the pathspec's Bloom key to pre-filter commits Toon Claes
2026-07-17 15:46 ` [PATCH 1/4] revision: move bloom keyvec precondition into function Toon Claes
2026-07-17 15:47 ` [PATCH 2/4] revision: expose check for paths maybe changed in Bloom filter Toon Claes
2026-07-17 20:47 ` Junio C Hamano [this message]
2026-07-17 15:47 ` [PATCH 3/4] last-modified: check pathspec against Bloom filter first Toon Claes
2026-07-17 15:47 ` [PATCH 4/4] last-modified: keep per-path Bloom filters for wildcard pathspecs Toon Claes
2026-07-17 19:16 ` Toon Claes
2026-07-17 19:13 ` [PATCH 0/4] last-modified: use the pathspec's Bloom key to pre-filter commits Toon Claes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqwlut1gzc.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gusted@codeberg.org \
--cc=peff@peff.net \
--cc=toon@iotcl.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox