Hi, Dag Sverre Seljebotn wrote: > Lisandro Dalcin wrote: >> On Wed, Sep 10, 2008 at 12:53 PM, Stefan Behnel <[EMAIL PROTECTED]> wrote: >>> Lisandro Dalcin wrote: >>>> On Wed, Sep 10, 2008 at 11:35 AM, Stefan Behnel <[EMAIL PROTECTED]> >>>> wrote: >>>>> This specific case is easy to handle as we can replace >>>>> PyObject_GetAttrString() by the equivalent PyObject_GetAttr() call and >>>>> create the Python string ourselves (which would normally happen inside >>>>> of PyObject_GetAttrString). >>>> As a reminder, please use PyString_InternFromString() (or the py3k >>>> equivalent). >>> I considered doing that and rejected it as I do not see the gain in >>> re-re-building the Python string instead of creating it once. Why do you >>> think this is necessary? >> Well, this is the way that PyObject_GetAttrString() is implemented. If >> the call ends-up doing many dicts lookups (think about the chain >> instance->class->[intermediate_class]->base_class), then using a >> interned string is much faster (as string comparison ends-up being a >> pointer comparison).
No, not in all cases. When the pointer comparison fails, Python still has to compare the strings. > In short, I believe this is a good optimization >> if Cython wants its own version of PyObject_GetAttrString() >> implemented in terms of PyObject_GetAttr(). We are totally not discussing our own GetAttrString() at this point (which is only used in a couple of less important places anyway). > I think Stefan is referring to a different approach: The string will be > created at module startup time and held on to. So your point is valid > but there's an even better approach :-) (assuming here that the module > startup interns the string, which seems very very likely but I didn't > check it). While true in general, this isn't currently done in this situation. The string is passed as a char*. We were discussing the specific case of importing a type from a module here, and the whole import machinery is so complex that it won't pay off to intern the class name at this point. It's a single lookup we are doing here, right after the entire module has been searched, imported and initialised. Interning the string will create it, look it up in the dictionary of interned strings, and then either insert or decref it, before it is finally looked up in the module dict and decrefed. The current implementation will create the string, look it up in the module dict and decref it. *That* is the faster way of doing it. Interning the string at module init time would only pay off if it's used elsewhere in a performance critical part of the code later on, which is not so likely for a class name. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
