2a fetch is very cpu intensive
Bug #562666 reported by
Michael Hudson-Doyle
This bug affects 4 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
High
|
Unassigned | ||
Breezy |
Triaged
|
Medium
|
Unassigned |
Bug Description
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.
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.
Changed in bzr: | |
status: | New → Confirmed |
importance: | Undecided → High |
tags: | added: 2a fetch performance |
tags: | added: check-for-breezy |
tags: | removed: check-for-breezy |
Changed in brz: | |
status: | New → Triaged |
importance: | Undecided → Medium |
To post a comment you must log in.
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