Re: [BUG] add_again() off-by-one error in custom format
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 19, 2017, 04:46 UTC
- Message-ID
- <xmqqd1a0vb2t.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20170618115017.wyroncb3jka6lrdt@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 29 quoted lines
> On Sun, Jun 18, 2017 at 12:58:49PM +0200, René Scharfe wrote: > >> Anyway, here's a patch for stat-based invalidation, on top of the other >> one. Array removal is really slow (hope I didn't sneak a bug in there, >> but my confidence in this code isn't very high). No locking is done; >> parallel threads removing and adding entries could make a mess, but >> that's not an issue for log. >> >> Timings for "time git log --pretty=%h >/dev/null" in my git repository >> with 5094 loose objects on Debian: >> >> master first patch this patch >> real 0m1.065s 0m0.581s 0m0.633s >> user 0m0.648s 0m0.564s 0m0.580s >> sys 0m0.412s 0m0.016s 0m0.052s >> >> >> And on mingw with 227 loose objects: >> >> master first patch this patch >> real 0m1.756s 0m0.546s 0m1.659s >> user 0m0.000s 0m0.000s 0m0.000s >> sys 0m0.000s 0m0.000s 0m0.000s >> >> So at least for Windows it would be really nice if we could avoid >> calling stat.. > > Thanks for doing the timings. Given those numbers and the earlier > discussion, I'd be inclined to skip the mtime check.
Yeah, thanks for these experiments. With or without invalidation, we already accept that racing with other processes will make the result inaccurate, so I am also inclined to say that it would be best to take the first one alone.