On Fri, Nov 09, 2018 at 02:43:52PM +0100, Ævar Arnfjörð Bjarmason wrote:
> As noted in
> https://public-inbox.org/git/87bm7clf4o@evledraar.gmail.com/ and
> https://public-inbox.org/git/87h8gq5zmc@evledraar.gmail.com/ I think
> it's regardless of Jeff's optimization is. O(nothing) is
On Sat, Nov 10, 2018 at 03:04:35PM +0100, Ævar Arnfjörð Bjarmason wrote:
> d) As shown in the linked E-Mails of mine you sometimes pay a 2-3 second
>*fixed* cost even for a very small (think ~100-200 objects) push/fetch
>that would otherwise take milliseconds with Jeff's version of this
>
On Thu, Nov 08, 2018 at 11:20:47PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Just a comment on this from the series:
>
> Note that it is possible for this to actually be _slower_. We'll do a
> full readdir() to fill the cache, so if you have a very large number of
> loose objects and a
On Fri, Nov 09 2018, Duy Nguyen wrote:
> On Fri, Nov 9, 2018 at 2:46 PM Ævar Arnfjörð Bjarmason
> wrote:
>> I'm planning to re-submit mine with some minor changes after the great
>> Documentation/config* move lands.
>>
>> As noted in
>>
On Fri, Nov 9, 2018 at 2:46 PM Ævar Arnfjörð Bjarmason wrote:
> I'm planning to re-submit mine with some minor changes after the great
> Documentation/config* move lands.
>
> As noted in
> https://public-inbox.org/git/87bm7clf4o@evledraar.gmail.com/ and
>
On Wed, Nov 07 2018, Geert Jansen wrote:
> On Mon, Oct 29, 2018 at 07:27:39PM -0400, Jeff King wrote:
>
>> On Mon, Oct 29, 2018 at 08:36:07PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> > * Re-roll my 4 patch series to include the patch you have in
>> >
On Thu, Nov 08 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 08 2018, Jeff King wrote:
>
>> On Wed, Nov 07, 2018 at 10:55:24PM +, Geert Jansen wrote:
>>
>>> On Mon, Oct 29, 2018 at 07:27:39PM -0400, Jeff King wrote:
>>>
>>> > On Mon, Oct 29, 2018 at 08:36:07PM +0100, Ævar Arnfjörð
On Thu, Nov 08 2018, Jeff King wrote:
> On Wed, Nov 07, 2018 at 10:55:24PM +, Geert Jansen wrote:
>
>> On Mon, Oct 29, 2018 at 07:27:39PM -0400, Jeff King wrote:
>>
>> > On Mon, Oct 29, 2018 at 08:36:07PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> > > * Re-roll my 4 patch series to include
On Thu, Nov 08, 2018 at 04:18:24PM -0500, Jeff King wrote:
> Heh, indeed. Try this on top:
>
> diff --git a/sha1-file.c b/sha1-file.c
> index bc35b28e17..9ff27f92ed 100644
> --- a/sha1-file.c
> +++ b/sha1-file.c
> @@ -692,6 +692,7 @@ void prepare_alt_odb(struct repository *r)
>
On Thu, Nov 08, 2018 at 08:58:19PM +, Geert Jansen wrote:
> On Thu, Nov 08, 2018 at 07:02:57AM -0500, Jeff King wrote:
>
> > Yes, testing and review. :)
> >
> > I won't send the series out just yet, as I suspect it could use another
> > read-through on my part. But if you want to peek at it
On Thu, Nov 08, 2018 at 07:02:57AM -0500, Jeff King wrote:
> Yes, testing and review. :)
>
> I won't send the series out just yet, as I suspect it could use another
> read-through on my part. But if you want to peek at it or try some
> timings, it's available at:
>
>
On Wed, Nov 07, 2018 at 10:55:24PM +, Geert Jansen wrote:
> On Mon, Oct 29, 2018 at 07:27:39PM -0400, Jeff King wrote:
>
> > On Mon, Oct 29, 2018 at 08:36:07PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > > * Re-roll my 4 patch series to include the patch you have in
> > >
On Mon, Oct 29, 2018 at 07:27:39PM -0400, Jeff King wrote:
> On Mon, Oct 29, 2018 at 08:36:07PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > * Re-roll my 4 patch series to include the patch you have in
> ><20181027093300.ga23...@sigill.intra.peff.net>
>
> I don't think it's quite ready for
On Mon, Oct 29, 2018 at 03:35:58PM -0700, Stefan Beller wrote:
> On Mon, Oct 29, 2018 at 3:27 PM Jeff King wrote:
>
> > So yeah, that's the other thing I'm thinking about regarding having a
> > maximum loose cache size.
>
> tangent:
> This preloading/caching could be used for a more precise
On Mon, Oct 29, 2018 at 08:36:07PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > Yeah, especially given recent advances in SHA-1 attacks, I'm not super
> > comfortable with the idea of disabling the duplicate-object check at
> > this point.
>
> I'd be comfortable with it in my setup since it's been
On Mon, Oct 29, 2018 at 3:27 PM Jeff King wrote:
> So yeah, that's the other thing I'm thinking about regarding having a
> maximum loose cache size.
tangent:
This preloading/caching could be used for a more precise approach
to decide when to gc instead of using some statistical sampling
of
On Mon, Oct 29, 2018 at 09:34:53PM +, Geert Jansen wrote:
> As an example, this means that when you're recieving a pack file with 1K
> objects in a repository with 10K loose objects that the loose-object-cache
> patch has roughly the same performance as the current git. I'm not sure if
>
On Mon, Oct 29, 2018 at 05:50:50PM -0400, Jeff King wrote:
> > I believe the loose-object-cache approach would have a performance
> > regression
> > when you're receiving a small pack file and there's many loose objects in
> > the
> > repo. Basically you're trading off
> >
> > MIN(256,
On Mon, Oct 29, 2018 at 09:34:53PM +, Geert Jansen wrote:
> On Mon, Oct 29, 2018 at 09:48:02AM +0900, Junio C Hamano wrote:
>
> > A real question is how much performance gain, relative to ".cloning"
> > thing, this approach gives us. If it gives us 80% or more of the
> > gain compared to
On Mon, Oct 29, 2018 at 09:48:02AM +0900, Junio C Hamano wrote:
> A real question is how much performance gain, relative to ".cloning"
> thing, this approach gives us. If it gives us 80% or more of the
> gain compared to doing no checking, I'd say we have a clear winner.
I've tested Jeff's
On Mon, Oct 29 2018, Jeff King wrote:
> On Sat, Oct 27, 2018 at 01:22:16PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > Taking one step back, the root problem in this thread is that stat() on
>> > non-existing files is slow (which makes has_sha1_file slow).
>> >
>> > One solution there is to
On Mon, Oct 29 2018, Jeff King wrote:
> On Mon, Oct 29, 2018 at 09:48:02AM +0900, Junio C Hamano wrote:
>
>> > Of course any cache raises questions of cache invalidation, but I think
>> > we've already dealt with that for this case. When we use
>> > OBJECT_INFO_QUICK, that is a sign that we
On Mon, Oct 29, 2018 at 09:48:02AM +0900, Junio C Hamano wrote:
> > Of course any cache raises questions of cache invalidation, but I think
> > we've already dealt with that for this case. When we use
> > OBJECT_INFO_QUICK, that is a sign that we want to make this kind of
> > accuracy/speed
On Sat, Oct 27, 2018 at 04:04:32PM +0200, Duy Nguyen wrote:
> > Of course any cache raises questions of cache invalidation, but I think
> > we've already dealt with that for this case. When we use
> > OBJECT_INFO_QUICK, that is a sign that we want to make this kind of
> > accuracy/speed tradeoff
On Mon, Oct 29, 2018 at 11:04:53AM -0400, Jeff King wrote:
> > Even if someone wants to make the argument that this is behavior that we
> > absolutely *MUST* keep and not make configurable, there's still much
> > smarter ways to do it.
>
> I don't have any real object to a configuration like
On Sat, Oct 27, 2018 at 01:22:16PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Taking one step back, the root problem in this thread is that stat() on
> > non-existing files is slow (which makes has_sha1_file slow).
> >
> > One solution there is to cache the results of looking in .git/objects
> >
Jeff King writes:
> Of course any cache raises questions of cache invalidation, but I think
> we've already dealt with that for this case. When we use
> OBJECT_INFO_QUICK, that is a sign that we want to make this kind of
> accuracy/speed tradeoff (which does a similar caching thing with
>
On Sat, Oct 27, 2018 at 11:34 AM Jeff King wrote:
> Taking one step back, the root problem in this thread is that stat() on
> non-existing files is slow (which makes has_sha1_file slow).
>
> One solution there is to cache the results of looking in .git/objects
> (or any alternate object store)
On Sat, Oct 27 2018, Jeff King wrote:
> On Sat, Oct 27, 2018 at 04:26:50PM +0900, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason writes:
>>
>> > But as Junio notes the devil's in the details, another one I thought of
>> > is:
>> >
>> > GIT_OBJECT_DIRECTORY=/some/other/repository git
On Sat, Oct 27, 2018 at 04:26:50PM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > But as Junio notes the devil's in the details, another one I thought of
> > is:
> >
> > GIT_OBJECT_DIRECTORY=/some/other/repository git clone ...
> >
> > It seems to me that ...
>
>
Ævar Arnfjörð Bjarmason writes:
> But as Junio notes the devil's in the details, another one I thought of
> is:
>
> GIT_OBJECT_DIRECTORY=/some/other/repository git clone ...
>
> It seems to me that ...
Actually I take all of that back ;-)
For the purpose of this patch, use of existing
On Fri, Oct 26 2018, Junio C Hamano wrote:
> "Jansen, Geert" writes:
>
>> The index-pack command determines if a sha1 collision test is needed by
>> checking the existence of a loose object with the given hash. In my tests, I
>> can improve performance of “git clone” on Amazon EFS by 8x when
"Jansen, Geert" writes:
> The index-pack command determines if a sha1 collision test is needed by
> checking the existence of a loose object with the given hash. In my tests, I
> can improve performance of “git clone” on Amazon EFS by 8x when used with a
> non-default mount option
The index-pack command determines if a sha1 collision test is needed by
checking the existence of a loose object with the given hash. In my tests, I
can improve performance of “git clone” on Amazon EFS by 8x when used with a
non-default mount option (lookupcache=pos) that's required for a Gitlab
34 matches
Mail list logo
