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

From: Jeff King <peff@peff.net>
Date: Jul 17, 2026, 08:09 UTC
Message-ID: <20260717080905.GC1832790@coredump.intra.peff.net>
In-Reply-To: <87se5jf9f7.fsf@emacs.iotcl.com>

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

Show 6 quoted lines

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

Show 6 quoted lines

> > +/*
> > + * 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