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 <[EMAIL PROTECTED]> <http://bugs.python.org/issue1564> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
