Rev 4769: Some comment cleanup, implement a special case for Py_EQ when both objects are intrened. in http://bazaar.launchpad.net/~jameinel/bzr/2.1-static-tuple-no-use
John Arbash Meinel
john at arbash-meinel.com
Mon Oct 12 19:02:11 BST 2009
At http://bazaar.launchpad.net/~jameinel/bzr/2.1-static-tuple-no-use
------------------------------------------------------------
revno: 4769
revision-id: john at arbash-meinel.com-20091012180207-gqjvwo80raq23gvq
parent: john at arbash-meinel.com-20091012175058-c2rosf9sz6dvk0a9
committer: John Arbash Meinel <john at arbash-meinel.com>
branch nick: 2.1-static-tuple-no-use
timestamp: Mon 2009-10-12 13:02:07 -0500
message:
Some comment cleanup, implement a special case for Py_EQ when both objects are intrened.
btree_mem_test.py doesn't show a significant impact. Real-world we probably
only use Py_EQ comparisons in sets and dicts when we get conflicts, also
note that we *don't* do the comparison for StaticTuple_Intern() because the
objects haven't been interned yet...
However, it seems 'correct' to do the check, so I'll leave it in.
-------------- next part --------------
=== modified file 'bzrlib/_static_tuple_c.c'
--- a/bzrlib/_static_tuple_c.c 2009-10-12 17:50:58 +0000
+++ b/bzrlib/_static_tuple_c.c 2009-10-12 18:02:07 +0000
@@ -364,10 +364,17 @@
return Py_False;
}
}
- /* TODO: if STATIC_TUPLE_INTERNED_FLAG is set on both objects and they are
- * not the same pointer, then we know they aren't the same object
- * without having to do sub-by-sub comparison.
- */
+ if (op == Py_EQ
+ && _StaticTuple_is_interned(v_st)
+ && _StaticTuple_is_interned(w_st))
+ {
+ /* If both objects are interned, we know they are different if the
+ * pointer is not the same, which would have been handled by the
+ * previous if. No need to compare the entries.
+ */
+ Py_INCREF(Py_False);
+ return Py_False;
+ }
/* The only time we are likely to compare items of different lengths is in
* something like the interned_keys set. However, the hash is good enough
@@ -559,8 +566,9 @@
};
/* TODO: Implement StaticTuple_as_mapping.
- * The only thing we really want to support from there is mp_subscript, so that
- * we could support extended slicing (foo[::2]). Not worth it yet, though.
+ * The only thing we really want to support from there is mp_subscript,
+ * so that we could support extended slicing (foo[::2]). Not worth it
+ * yet, though.
*/
More information about the bazaar-commits
mailing list