calling for dirstate dogfooders, and change in branch policy now all tests pass

[Robert Collins]

On Thu, 2007-03-01 at 09:10 -0600, John Arbash Meinel wrote:


> >  - Figure out the regression on xml based trees (???) (I am guessing its
> > a hashcache usage issue - should be simple)
> 
> I've done profiling, and I'm pretty convinced this is not genuine. When
> I did a 'bzr --lsprof status' I had a difference of about 40ms out of 1s
> but bzr.dev was actually the slower one.
> 
> Running 'timeit bzr status' on the launchpad tree I have 1.93s with
> bzr.dev, and 1.97s with dirstate. 40ms is well within the noise margin.
> Or at least not worth spending a lot of time yet.  (running it again I
> got 1.87s for dirstate)

With mozilla I have these three times:
616 seconds: XML, bzr.dirstate 
11 seconds: XML, /usr/bin/bzr
7 seconds: dirstate, bzr.dirstate

*something* is wrong.

> >  - Remove the use of a regular hashcache completely, which will reduce
> > parse time further still for dirstate tree operations. (???)
> > 
> 
> I'll see about taking up hashcache operations. I also know that my
> bisect code is imperfect at the moment (it doesn't take into account the
> new sorting rules). So I'll probably fix that up first, and then go into
> the hash cache stuff.

Cool.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070302/de29283e/attachment.pgp