On Dec 8, 7:22 pm, Yarko Tymciurak <[email protected]> wrote: > On Dec 7, 10:25 pm, dmuir <[email protected]> wrote: > > > Thadeus, > > Apologies for butting in on this list... but the links you gave show > > exactly why it's important to run your own tests. The comparisons are > > *very* out-dated. There have been over 16 releases of Bazaar since > > then. I don't follow hg or git development, but I'm guessing they've > > had a few releases since then as well... > > > Overall, Yarko's comparisons are more between Launchpad and Google > > Code than bzr vs hg.
I think that's true, and in particular probably two things: * Launchpad running over ssh which has much more startup overhead than http <https://bugs.edge.launchpad.net/launchpad-code/+bug/165087> * Google (and maybe Yarko?) being in the US, and Launchpad in the UK > *sigh* - yes, it would appear that _might_ be so, and I agree - you > should take your own measures... > > Let me look at a machine local hg clone of the same, and compare it to > a machine local bzr branch. The way I did this: the web2py hg clone > from google code copied, revision history cleared, and then the tree > init'd with each, and then cloned/branched. > > hg : 0.514s > bzr: 2.236s > > so now it's only ~1/2 an order of magnitude difference (Bigtable, and > Google resources no doubt had impact). Thanks for being open to re-measuring this. It's not quite apples-to- apples because hg will be hardlinking the repository files whereas bzr does not - there are pros and cons to this but I won't repeat them here. At any rate the recommended setup with Bazaar is to make a shared repository directory, and that causes Bazaar to do similar work to hg. With that, on my machine: bzr init-repo test rm -r foo/.hg bzr init foo bzr add foo bzr ci -m snapshot foo m...@grace% time bzr branch foo bar Branched 1 revision (s). bzr branch foo bar 0.63s user 0.10s system 94% cpu 0.776 total > The thing I will point out, regardless of the numbers, the experience > is born out. Yes, we made it _much_ worse by vresioning compressed > tar files (shame on us); this really exacerbated the situation. > Even so, the feel of hg has always seemed faster (locally, you can > _feel_ this), and these numbers (however empirical) so far bear that > out. If it does seem to you that it feels faster, then that's true, and I would expect there are cases where hg is somewhat faster. In particular we load more Python files when getting started than we should, and this causes lag especially on a cold cache. But in our measurements it is normally pretty close, so if there are things where it is enough to be a problem, we'd really like to either know about them or help you find ways around it. -- Martin -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
