-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 5/5/2011 11:22 PM, Martin Pool wrote:
On 5 May 2011 18:19, Andrew Stubbs andrew.stubbs@linaro.org wrote:
On 05/05/11 16:22, Martin Pool wrote:
I filedhttps://bugs.launchpad.net/bzr-rewrite/+bug/777920 to track this. I think it will have been improved a fair bit by John's recent work on huge-tree workingtree performance work (which sped up some things like revert 8x) but there's probably more to do. That work is in bzr 2.4beta, which you can get from eg ppa:bzr/daily.
I certainly have witnessed revert being very slow.
In fact, I'd say it feels quicker to run "bzr st" and then do "bzr revert" naming individual files. Maybe that's illusory, but it's certainly quicker to revert individual files if you already have the list to hand. Of course, that doesn't revert merge notes, so it's perhaps not exactly the same.
I think that's consistent with the bug that was recently fixed. If you still see this in current bzr 2.4beta, please let me know.
It hasn't actually landed yet because the revert patch conflicted with TreeReferences, which I had an initial fix for, but had yet more fallout in another section with TreeReferences. (nested-subtrees which is unfinished work in our codebase.)
I hope to have that finished off and landed today.
Uncommit is another command that seems unreasonably slow. It really shouldn't be that hard to do a "patch -R" and update some metadata somewhere, but clearly there's a lot more to it than that!
I think that's the same.
Martin
Uncommit has to rewrite the whole dirstate file because we are storing the inventory of the basis revision to make things like "bzr st" fast. (uncommit trivially moves the branch pointer, and then not-quite-so-trivially tells the working tree that it has a new basis revision.)
It is possible that we could be lighter weight about the basis revision change. Instead of telling it "you are now pointing at X", tell it "you are pointing at X, and here is the delta between Y and X".
I think the main issue for uncommit (minutes) is that it would walk the whole basis inventory from the repository in a bad way. *That* should be fixed in bzr-2.4b2 (we'll walk the basis inventory in a faster way, ~10s). If we did a delta approach, we could probably get that down to <1s.
Rewriting the dirstate file itself would then be the primary bottleneck, I think.
In 2.4b? most commands that took >3min in my testing dropped into the <30s range because of improved ordering while walking the inventory. There are still a few more that can be improved a bit further.
John =:->