[issue1564] The set implementation should special-case PyUnicode instead of PyString
Christian Heimes
report at bugs.python.org
Mon Dec 10 01:48:22 CET 2007
Christian Heimes added the comment:
Raymond Hettinger wrote:
> Which is the common case in Py3k, to have strings or unicode? By
> trying to catch both, you slow down the optimization. Also, the
> new "hash_fast" introduces function call overhead in previously in-
> lined code.
PyUnicode is the common case for dict keys in py3k. Attributes etc. are
all PyUnicode instances.
> For sets, I prefer the code to be left as it is. For dicts, whatever
> you do, don't slow-down the common case of regular attribute lookup.
> This is some of the most time critical code in the language. Trying to
> generalize the optimization, make actually make it slower.
I wonder how I should store unicode_eq. It's required for dict and set
optimization and I like to keep it static inline. But I can't access
unicode_eq in setobject.c when it is declared as static in dictobject.c.
I could either declare unicode_eq as extern or I could put the method
into a header file which is included by both c files.
> If unicode strings are the norm and an not PyString_Objects, then
> switch to that one, but I don't think you should try to do both.
Understood!
Christian
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1564>
__________________________________
More information about the Python-bugs-list
mailing list