On Tue, 2010-04-13 at 23:55 +0000, Michael Hudson wrote:
> Public bug reported:
>
> Because 2a fetch validates and filters the data it transfers, it is uses
> a lot of cpu -- for example, fetching an imported kernel (over a high
> bandwidth low latency link) uses about an hour of cpu time. git does it
> in about 20 seconds.
It would be good to validate that this is actually a full fetch and sha
validate by git; it may not be.
> There are reasons for done the validation and filtering, but perhaps
> there's a place for a dumb copy? I think Something Needs To Be Done, in
> any case.
I agree; in particular the use case Michael cares about here is fetching
over a LAN to make a temporary branch copy to work on. So local disk
'tricks' like hardlinking won't help at all: we need to make actual
fetch more efficient.
On Tue, 2010-04-13 at 23:55 +0000, Michael Hudson wrote:
> Public bug reported:
>
> Because 2a fetch validates and filters the data it transfers, it is uses
> a lot of cpu -- for example, fetching an imported kernel (over a high
> bandwidth low latency link) uses about an hour of cpu time. git does it
> in about 20 seconds.
It would be good to validate that this is actually a full fetch and sha
validate by git; it may not be.
> There are reasons for done the validation and filtering, but perhaps
> there's a place for a dumb copy? I think Something Needs To Be Done, in
> any case.
I agree; in particular the use case Michael cares about here is fetching
over a LAN to make a temporary branch copy to work on. So local disk
'tricks' like hardlinking won't help at all: we need to make actual
fetch more efficient.
-Rob