[MERGE] BEncode Revision Serializer

[Jelmer Vernooij]

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

Hi John,

John Arbash Meinel wrote:
>
> ...
>
>> Anyway, I would like to postpone landing this until I've gotten
>> some numbers for comparing it to the RIO based serializer, and
>> our existing XML based one. (Size/speed/etc).
>
>> I'll try to get that done today.
>
>> BB:comment
>
>> (I'm not really sure that we have a BB:wait until I give a full
> review :)
>
>> John =:->
>
> So here are the start of some numbers. This is the size of just the
>  'revisions' portion after compression.
>
> Raw    %    Compressed    %  Objects dev6             3990 KiB   0%
> 632 KiB   6%     1043 dev7-bencode     3851 KiB   0%       647 KiB
> 6%     1043 dev6-rio         3840 KiB   0%       632 KiB   6%
> 1043
>
> Notice that dev7-bencode is the largest of the group and
> dev6/dev6-rio are about the same size.
>
> I'm 75% sure that this is because we don't control the ordering of
> the data in the bencode form.
>
> Time to extract all 1000 Revisions: $ TIMEIT -s "b =
> Branch.open('dev7-rio/m'); b.lock_read(); \ revs =
> b.repository.get_ancestry(b.last_revision()); revs.pop(0); \
> b.repository.get_revisions(revs)" \ # Seed the request to avoid
> index "b.repository.get_revisions(revs)"
>
> dev6        157 msec per loop dev7-bencode    158 msec per loop
> dev7-rio    106 msec per loop
>
> Now, mysql revs are a bit a-typical because they have large
> revision properties, with bencoded per-file messages.
>
> Given that bencode is both larger and slower, though....
>
> Now, I realize that 'slower' seems to contradict what Jelmer saw
> when benchmarking a single revision deserialized lots of times.
>
> Given the above, though, it would seem prudent to benchmark both
> the RIO serializer and the BEncode serializer using UserTest and a
> bigger dataset (like all of bzr.dev as a baseline, but MySQL would
> be nice...)
Is this with both the BEncode revision serializer and the BEncode
Pyrex patch? I only saw the performance improvements with both.

Cheers,

Jelmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iJwEAQECAAYFAkokVjsACgkQDLQl4QYPZuWx5wP9Fv8dJ4qkuhOSej5hZn8iRT51
YB5FBDNssWTge7MwkComhbQp21GRMRLgT4K79/gdhMBlJOLbtoJzVxB7jcL26m4U
ZxHsxij/P4LVO3WkjPR91benfN/eJE3X/u0AEqQn8S15+muoa5fXQhpmJwf3onxH
VgnsRK5jrUrkpm7kDL0=
=ALvC
-----END PGP SIGNATURE-----