brisbane:CHKMap.iteritems() tweaks

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
...

>>> I guess that is 300KiB. But out of 125MiB, that is only 0.2%.
>> Well worth it IMO.
> 
> So I've done a bit of playing with this. Specifically, I felt that if
> you want to pull out the most recent 100 revs of chk pages, then you
> probably also want to pull out the most recent texts.
> 
> Pulling out the texts has a much larger impact on total size. Going from
> 124MB => 140MB. At best guess, it is that we are now storing a fulltext
> for every file in the working tree. In testing, it didn't matter if I
> set the threshold at 10 revs, 100 revs and 1000 revs. 1000 revs was
> actually bigger than 100 revs.
> 

...

> I tested the "bzr co" time for the two different cases, to see if we see
> a big difference.
> 
> So in testing, 'bzr ls -r-1' time, it didn't seem to matter whether I
> packed at 10 revs or 1000 revs. They both gave me a time of 6-8s without
> special sorting, and 2.7s with special sorting.
> 
> As for sorting the file texts. With the split at 100 revs I see:
> 
> time bzr co lp-100
> 10.9s
> time bzr co lp-100-no-texts
> 12.9s
> 
> So we save ~2s during extracting the texts time. (This is with my fix to
> TT.create_file(string) to use f.write() rather than f.writelines())


The other thing I was thinking about, is the "bzr branch --stacked" sort
of case. Which is something that the python guys would really like. If
you have all of the content to reproduce a workingtree expanded up at
the front of your repository, it means that 'bzr branch --stacked'
*only* needs those blocks, and doesn't need to download the rest of the
history at all. In theory a smart server would generally do some work to
give you ~ the same small number of bytes, but this would be a way you
could do it even over a dumb transport.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknKRV4ACgkQJdeBCYSNAAM2fACeMiim005H/ZHrtZ+v8Elz3TrK
vxQAn38zRWMwCkBBcmnLdxTjiTpeJyB+
=O23K
-----END PGP SIGNATURE-----