Rev 4768: Comment about compiled code quality. in http://bazaar.launchpad.net/~jameinel/bzr/2.1-static-tuple-btree-string-intern
John Arbash Meinel
john at arbash-meinel.com
Mon Oct 12 21:07:13 BST 2009
At http://bazaar.launchpad.net/~jameinel/bzr/2.1-static-tuple-btree-string-intern
------------------------------------------------------------
revno: 4768
revision-id: john at arbash-meinel.com-20091012200709-hjmn47sbqw12fzpt
parent: john at arbash-meinel.com-20091012200227-dc9uy4l5487eezcy
committer: John Arbash Meinel <john at arbash-meinel.com>
branch nick: 2.1-static-tuple-btree-string-intern
timestamp: Mon 2009-10-12 15:07:09 -0500
message:
Comment about compiled code quality.
-------------- next part --------------
=== modified file 'bzrlib/_btree_serializer_pyx.pyx'
--- a/bzrlib/_btree_serializer_pyx.pyx 2009-10-12 19:50:25 +0000
+++ b/bzrlib/_btree_serializer_pyx.pyx 2009-10-12 20:07:09 +0000
@@ -356,6 +356,11 @@
# And when there are 2 items, we could do a single malloc + len() + 1
# also, doing .join() requires a PyObject_GetAttrString call, which
# we could also avoid.
+ # TODO: Note that pyrex 0.9.6 generates fairly crummy code here, using the
+ # python object interface, versus 0.9.8+ which uses a helper that
+ # checks if this supports the sequence interface.
+ # We *could* do more work on our own, and grab the actual items
+ # lists. For now, just ask people to use a better compiler. :)
string_key = '\0'.join(node[1])
# TODO: instead of using string joins, precompute the final string length,
More information about the bazaar-commits
mailing list