Re: git-last-modified(1) slower than git-log(1)?

[Jeff King <peff@peff.net>]

On Thu, Jul 16, 2026 at 01:42:04PM +0200, Toon Claes wrote:

> >   - more timing exploration; e.g., might it make things worse if
> >     doc/langref were touched in 99% of the commits? Probably not, but it
> >     might be nice to check timings against a few repo shapes and request
> >     depths.
> 
> Maybe, I tried a few things.

Yeah, I would be surprised to find a practical case where it makes
things slower. Checking one bloom key is cheap-ish, and unless the
subtree being queried is touched by almost every commit, it's going to
be a net win.

> Personally I'm not too worried any use-case would be at least equally
> fast.

So yeah, that's my gut feeling, too.

> > +/*
> > + * revision.c already has this functionality, but it is not public
> > + * and it looks up the filter itself. But probably some refactoring
> > + * could make it available at the right level?
> 
> I assume you're talking about check_maybe_different_in_bloom_filter()?

Yeah, exactly. We already do the first half (getting the commit's
filter) ourselves. And then most of the rest is just trace2 accounting,
which we don't necessarily need to do.  So we're left with just that one
bloom over the keyvecs, which is fairly trivial. Mostly it felt weird to
be looking at the innards of rev_info, and the logic for what those
keyvecs means should remain in revision.c.

> I was working on a fix to simply make it public and call it, but that's
> a very valid point you're making. I'll change my plans.

I was just thinking to split it into two (get the filter, and then check
the filter against the rev_info) and make the latter half public.

-Peff