[MERGE] pyrex bencode implementation

[Alexander Belchenko]

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

Aaron Bentley пишет:
> 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.

OK, fair enough. I wrote this code for myself as learning exercise.
Thanks for explanation. I'd like to reject this patch in the end.

[µ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxAmNzYr338mxwCURAiP7AJ9p2bctgx9v07i/iqUtG5wv032IFgCePxfE
W4Fyp2+jYGcqBeAwAQ9x63g=
=pFUT
-----END PGP SIGNATURE-----