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