performance analysis for update

[Jelmer Vernooij]

Attached are the notes I wrote during the performance analysis of update
we did in London. Should I send in a bundle or something that adds this
to doc/developer/ ? Comments on the contents / formatting are also
welcome.

Cheers,

Jelmer
-------------- next part --------------
"bzr update" performance analysis
=================================

There are 5 different slightly different code paths in which bzr update 
can be used:

* local only (no-op)
* lightweight checkout
* heavy checkout
* heavy checkout w/ local commits
* bzr update could work on "bound branch" w/no wt

No new revisions
================
should be O(1) to determine
tree base is up to date
wt.last-rev == wt.b.last-rev

no local changes, only new revcs
=================================
1) need to move wt.last_rev (O(1))
2) apply delta from base to new rev O(Changes)
applying diffs to files is approx O(size-of-changed-files)

3) update meta-info about modified files O(Changes) -> O(tree)
done as we apply the changes to the wt 

2/3 could be concurrent

ptotential issue w/ serialized is have 50k files in limbo/

could build new files in new dirs "in place" rather than at toplevel

modifying in place: reduce fragmentation of fs, not atmic
w/ local modification, potiential dataloss
w/o should be safe

"local mod" is diff between disk and last commit, not merge base

defecting name conflicts should be O(siblings)

create allocate siblings before write

"bzr revert -rOTHER foo"

out of date heavyweight checkout, out of date w/master
=======================================================
1) open wt check last rev
2) open wt.b check last rev
3) mismatch => update wt => wt.b.lastrev
apply delta to tree O(changed file size)
---- conflicts
stop on conflicts
stop always -> inform user they need to repeat (why not?, GFD)
4) pull new revs M => L O(newrevs)
5) apply delta to wt
local committed changes become a pending merge
local uncommitted stay uncommitted
local pending merges are retained (should be gc'd)

offtopic:
should bzr update report where the source is ?
should bzr update handle both cases (local tree out-of-date w/local branch, checkout out-of-date w/master) ?

if updating would diverge, give opportuniuty to branch/unbind instead
local ahead, "push to master"

ideas:
1) can this be done as a single logical step
2) can this be done w/o modifying working tree until end - possible perf improvements
3) if the pulling revision step could deliver full texts, that may help for the merge (same thing as "bzr pull")
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070712/386a8849/attachment.pgp