[MERGE] pyrex bencode implementation

[Aaron Bentley]

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

Alexander Belchenko wrote:
> Aaron Bentley ?8H5B:
>> For all I know, your performance win comes simply from avoiding function
>> call overhead, and that could be fixed without Pyrex.
> 
> I think it's not quite true. In decode I also avoid numerous memory
> allocations for each intermediate value.

I'm not saying that avoiding function call overhead is the sole reason
for your speed increase.  I'm saying that I don't *know* why your code
is faster, without more data.  The intermediate memory allocations may
or may not be an observable cost.

>> HACKING says a patch should "Improves bugs, features, speed, or code
>> simplicity"
> 
> (Or scratch the itch of patch's author?)

Not that kind of itch.  You can add features, squash bugs, improve
real-world speed, or simplify code.  You can't just write code because
you want to.  Sorry.

>> This patch reduces code simplicity, and the speed increases don't seem
>> to be substantial.
> 
> I think you're right. But in this case your vote is incorrect.
> I expecting bb:reject.

Yes, but I wanted to give you a chance to rebut me first.  Perhaps you
had other benchmarks that would sway me.

I should say about simplicity:
- - Pyrex code is less simple than Python code in general.
- - Having two implementations, one in Python, one in Pyrex, is less
  simple than having one implementation.

I would only use Pyrex for things that aren't fast enough in pure Python.

> I also asked about kind of data that serialized with bencode by another
> part of bzrlib but nobody answer me:

Actually, I participated in that discussion:
http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/29112

"Bundle format 4 uses bencode very heavily, so there might be an
observable difference there."

You replied to my message, so don't claim you never saw it.

If you can show that speeding up bencode speeds up pull from a bundle,
significantly, I think that would justify merging it.

But in general, it does not make sense to start by making code changes
and then look for the performance benefits.  It should always start with
 a macro operation you want to speed up, like "commit" for Ian, "status"
for John, or "merge, diff, and checkout" for me.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGw1gN0F+nu1YWqI0RAn/VAJ9X1vIt32Iw6GJNMa8vCrY9axmkeACfeYAJ
JWR09SbexRDCbyFq4T6ePeU=
=ITyF
-----END PGP SIGNATURE-----