From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: "René Scharfe" <l.s.r@web•de>,
"Michael Giuffrida" <michaelpg@chromium•org>,
git@vger•kernel.org, "SZEDER Gábor" <szeder.dev@gmail•com>
Subject: Re: [BUG] add_again() off-by-one error in custom format
Date: Sun, 18 Jun 2017 21:46:34 -0700 [thread overview]
Message-ID: <xmqqd1a0vb2t.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170618115017.wyroncb3jka6lrdt@sigill.intra.peff.net> (Jeff King's message of "Sun, 18 Jun 2017 07:50:17 -0400")
Jeff King <peff@peff•net> writes:
> 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.
next prev parent reply other threads:[~2017-06-19 4:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-12 3:13 [BUG] add_again() off-by-one error in custom format Michael Giuffrida
2017-06-12 22:49 ` Junio C Hamano
2017-06-13 18:09 ` René Scharfe
2017-06-13 18:29 ` Junio C Hamano
2017-06-13 20:29 ` René Scharfe
2017-06-13 21:20 ` Junio C Hamano
2017-06-14 18:24 ` René Scharfe
2017-06-15 5:56 ` Jeff King
2017-06-15 11:33 ` René Scharfe
2017-06-15 13:25 ` Jeff King
2017-06-18 10:58 ` René Scharfe
2017-06-18 11:49 ` Jeff King
2017-06-18 12:59 ` René Scharfe
2017-06-18 13:56 ` Jeff King
2017-06-22 18:19 ` René Scharfe
2017-06-22 23:15 ` Jeff King
2017-06-18 10:58 ` René Scharfe
2017-06-18 11:50 ` Jeff King
2017-06-19 4:46 ` Junio C Hamano [this message]
2017-06-22 18:19 ` [PATCH] sha1_name: cache readdir(3) results in find_short_object_filename() René Scharfe
2017-06-22 23:10 ` Jeff King
2017-06-24 12:12 ` René Scharfe
2017-06-24 12:14 ` Jeff King
2017-06-24 12:12 ` René Scharfe
2017-06-24 12:20 ` Jeff King
2017-06-24 14:09 ` René Scharfe
2017-06-24 14:12 ` Jeff King
2017-06-15 18:37 ` [BUG] add_again() off-by-one error in custom format Junio C Hamano
2017-06-13 22:24 ` SZEDER Gábor
2017-06-14 17:34 ` René Scharfe
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=xmqqd1a0vb2t.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=l.s.r@web$(echo .)de \
--cc=michaelpg@chromium$(echo .)org \
--cc=peff@peff$(echo .)net \
--cc=szeder.dev@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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