On Mon, Dec 14, 2015 at 02:31:55PM -0800, Jonathan Nieder wrote:
> > I suspect there's room for improvement in the way we select commits to
> > store bitmaps for (so that the average walk is smaller). But it's rather
> > tricky; there's not a single constant to change to make it work better.
>
>
Jeff King wrote:
> Hmm. I guess that makes sense. The bitmap we want is the set difference
> between the objects we are sending, and the tips the other side has. If
> we have a bitmap at each ref tip, that's very fast. But if you have a
> very large number of refs, we don't make one for each ref,
On Mon, Dec 14, 2015 at 01:47:39PM +, Daniel Koverman wrote:
> > You might also try repacking with "git repack -adb", which will
> > build reachability bitmaps. Pack-objects can use them to compute
> > the set of required objects much faster.
>
> Running "git repack -adb" caused my push time
> You might also try repacking with "git repack -adb", which will
> build reachability bitmaps. Pack-objects can use them to compute
> the set of required objects much faster.
Running "git repack -adb" caused my push time to incease by about 5x.
I made some fresh clones and tried other options wit
> On Dec 9, 2015, at 9:19 PM, Jeff King wrote:
>
> On Tue, Dec 08, 2015 at 05:34:43PM +, Daniel Koverman wrote:
>
>> It is also good to know that 2000 remote refs is insane. The lower
>> hanging fruit here sounds like trimming that to a reasonable
>> number, so I'll try that approach first.
On Tue, Dec 08, 2015 at 05:34:43PM +, Daniel Koverman wrote:
> Your interpretation of my email was correct. As you picked up on, I
> had a fundamental misunderstanding of what pack-objects was doing.
> Thanks for the explanation, I have a much better idea of what is
> going on now.
>
> Given
first.
Thanks again, Junio and Peff.
Daniel
-Original Message-
From: Jeff King [mailto:p...@peff.net]
Sent: Monday, December 07, 2015 5:57 PM
To: Daniel Koverman
Cc: Junio C Hamano; git@vger.kernel.org
Subject: Re: Why does send-pack call pack-objects for all remote refs?
On Mon, Dec 07, 20
On Mon, Dec 07, 2015 at 02:41:00PM -0800, Junio C Hamano wrote:
> Also it was unclear if you are working with a shallow repository.
> The performance trade-off made between the packsize and the cycles
> is somewhat different between a normal and a shallow repository,
> e.g. 2dacf26d (pack-objects:
Daniel Koverman writes:
> I have a repository which has ~2000 branches on the remote, and it
> takes ~8 seconds to push a change to one ref. The majority of this
> time is spent in pack-object. I wrote a hack so that only the ref
> being updated would be packed (the normal behavior is to pack for
I have a repository which has ~2000 branches on the remote, and it takes ~8
seconds to push a change to one ref. The majority of this time is spent in
pack-object. I wrote a hack so that only the ref being updated would be packed
(the normal behavior is to pack for every ref on the remote). The
10 matches
Mail list logo