Author christian.heimes
Recipients christian.heimes, gvanrossum, rhettinger
Date 2007-12-10.00:48:22
SpamBayes Score 0.000357902
Marked as misclassified No
Message-id <475C8CD6.10402@cheimes.de>
In-reply-to <1197239951.49.0.522047356998.issue1564@psf.upfronthosting.co.za>
Content
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
History
Date User Action Args
2007-12-10 00:48:22christian.heimessetspambayes_score: 0.000357902 -> 0.000357902
recipients: + christian.heimes, gvanrossum, rhettinger
2007-12-10 00:48:22christian.heimeslinkissue1564 messages
2007-12-10 00:48:22christian.heimescreate