[jblack: Re: [tools-discuss] Evaluation notes on bzr-0.7]
James Blackwell
jblack at merconline.com
Tue Feb 28 19:58:36 GMT 2006
----- Forwarded message from jblack -----
To: tools-discuss at opensolaris.org
Subject: Re: [tools-discuss] Evaluation notes on bzr-0.7
The two quick answers to your question are thus:
1. Its possible that you do not have python2.4-celementree installed.
Though Bazaar-NG does run without it, the performance is a bit slower.
Would you be willing to rerun your tests with celementree installed?
2. Yes, we're planning on a 0.8 release within the month. This includes a
30x performance improvement as we move from weaves to knits (which are
an append only methodology).
I'll forward a copy of your email to the bazaar-ng list and reply back to
this list any extenuating information that they provide.
Regards,
James
On Tue, Feb 28, 2006 at 11:34:05AM -0800, Stephen Hahn wrote:
>
> Although we began the evaluation with 0.6.2, I moved to 0.7 since it
> became available. I also installed bzrtools-0.7, mostly to get push.
> All timings were done on a single system using local filesystems.
> Elapsed times from the truss output should be ignored.
>
> I think we can keep bzr in the evaluation if we see evidence of a
> release candidate that actually addresses the performance issues.
>
> - Stephen
>
> ----
>
> Questions/comments:
>
> 1. Performance of 0.7 is a problem, beyond the initial branch issue.
> Is bzr not changeset aware? Operations such as commit appear to
> scan the entire repository in an expensive manner. Can you
> suggest workarounds?
>
> As an example, the "bzr init" operation seems reasonable with
> "truss -c bzr init" showing
>
> syscall seconds calls errors
> _exit .000 1
> read .314 41544
> write 2.618 296080
> open .000 45 1
> close .353 48368
> time .000 2
> chmod .000 1
> brk .057 4168
> getpid .000 4
> sysi86 .000 1
> ioctl .000 131 129
> execve .000 1
> fcntl .040 6898
> openat .124 6890
> readlink .000 2 2
> sigaction .000 52
> sigfillset .000 1
> getcontext .000 1
> setustack .000 1
> mmap .002 187
> munmap .000 66
> xstat .000 66 22
> getrlimit .000 1
> memcntl .001 41
> rename .000 2
> sysconfig .000 8
> sysinfo .000 2
> lwp_private .000 1
> llseek .001 280
> resolvepath .000 46
> getdents64 .418 13789
> stat64 .021 650 592
> lstat64 1.079 41172 2
> fstat64 .048 7425
> open64 2.123 50327 8892
> getcwd .000 3
> -------- ------ ----
> sys totals: 7.209 518257 9640
> usr time: 75.916
> elapsed: 150.250
>
> so that we're roughly performing 1 open(), 1 close(), and 1 lstat() per
> file. The following commit is expensive, but that's because
> we're adding the 34 000 files:
>
> syscall seconds calls errors
> _exit .000 1
> read 7.107 204522
> write 6.090 279572
> open .000 45 1
> close 1.979 116932
> time .000 2
> chmod .819 41421
> brk .018 1650
> getpid .228 41168
> getuid .000 2
> access .000 3 2
> sysi86 .000 1
> ioctl .437 75577 75575
> execve .000 1
> fcntl .037 6897
> openat .103 6890
> mkdir 1.620 41160 40903
> readlink .000 2 2
> sigaction .000 52
> sigfillset .000 1
> getcontext .000 1
> setustack .000 1
> mmap .002 187
> munmap .000 66
> xstat .000 66 22
> getrlimit .000 1
> memcntl .001 41
> rename 10.843 41165
> sysconfig .000 8
> sysinfo .248 41167
> lwp_private .000 1
> llseek .813 137400
> door_info .000 2
> door_call .000 2
> resolvepath .000 46
> getdents64 .934 13789
> stat64 .028 655 597
> lstat64 4.294 150896 1
> fstat64 1.792 302321
> open64 10.664 194338 84338
> getcwd .000 2
> -------- ------ ----
> sys totals: 48.070 1698054 201441
> usr time: 150.255
> elapsed: 409.150
>
> My concern arises when we change a single file, do an add, and
> then commit:
>
> syscall seconds calls errors
> _exit .000 1
> read 10.605 153945
> write 1.590 167132
> open .000 45 1
> close .676 82666
> unlink .000 1
> time .000 2
> chmod .000 7
> brk .047 5889
> getpid .000 10
> getuid .000 2
> access .000 5 2
> sysi86 .000 1
> ioctl .241 41310 41308
> execve .000 1
> fcntl .038 6897
> openat .109 6890
> mkdir .000 2 1
> readlink .000 2 2
> sigaction .000 52
> sigfillset .000 1
> getcontext .000 1
> setustack .000 1
> mmap .002 187
> munmap .000 66
> xstat .000 66 22
> getrlimit .000 1
> memcntl .001 41
> rename .001 6
> sysconfig .000 8
> sysinfo .000 9
> lwp_private .000 1
> llseek .856 144293
> door_info .000 2
> door_call .000 2
> resolvepath .000 46
> getdents64 .978 13789
> stat64 .022 655 597
> lstat64 5.760 150882
> fstat64 1.200 199522
> open64 2.866 77754 2020
> getcwd .000 2
> -------- ------ ----
> sys totals: 25.003 1052195 43953
> usr time: 62.932
> elapsed: 1037.130
>
> There needs to be a way to treat small declared operations
> precisely, and without scanning the entire tree. Perhaps I
> missed something in the documentation.
>
> 2. push is non-primitive; we're using bzrtools-0.7's implementation.
> This operation is central to our use of any DSCM, so I would like
> to understand why it's not considered a first class operation.
>
> 3. One problem I ran into was the lack of support for "selected file
> commits" when a merge was pending:
>
> $ bzr commit .
> bzr: ERROR: exceptions.NotImplementedError: selected-file commit of
> merges is not supported yet
>
> '.' is the lowest directory common to all merged files; this
> defect means that we scan the entire repository to resolve the
> merge.
>
> 4. Documentation for bzr is promising in places, but incomplete.
>
>
> --
> Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
> stephen.hahn at sun.com http://blogs.sun.com/sch/
> _______________________________________________
> tools-discuss mailing list
> tools-discuss at opensolaris.org
----- End forwarded message -----
--
My home page: <a href="http://jblack.linuxguru.net">James Blackwell</a>
Gnupg 06357400 F-print AAE4 8C76 58DA 5902 761D 247A 8A55 DA73 0635 7400
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060228/0551290e/attachment.pgp
More information about the bazaar
mailing list