Stefan Behnel wrote: > Hi, > > there are a couple of tickets related to call optimisations. > > http://trac.cython.org/cython_trac/ticket/3 > http://trac.cython.org/cython_trac/ticket/131 > http://trac.cython.org/cython_trac/ticket/166 > > The getattr3() problem also relates to other cases, such as the fact that > we can't currently optimise > > cdef list l = [...] > l.sort() > > into a call to PyList_Sort(), as this would break calls like > > l.sort(key=...) > > My suggestion is to remove the current support for optimised methods of > builtins, and to write a dedicated transform that intercepts the tree on > call nodes and that can then handle all cases in explicit code. This can > include, for example, adding a None check if required, or handling > different call signatures only some of which can be optimised, maybe even > by changing keyword arguments into positional arguments of a matching > C-API function. > > I imagine that it would use some kind of dispatch mechanism on > > (obj_type, obj_attribute_name) > > and on builtin function names. I also think that the current generic > "X.append()" optimisation (i.e. not only the one for typed lists) should > go there.
Sounds good! One thing: I think it would be good if the output is something very targeted (i.e. not simply new SimpleCallNodes or similar). From the refnanny it seemed that very many CPython API calls used the same pattern, so perhaps something along the lines of a PythonApiCall-node, perhaps with a NoneCheckNode as its "subject", and so on. (Some of the resulting operations could warrant their own node, while others are similar enough to not warrant new classes for each -- the point is that I think it should be more "targeted" than new SimpleCallNodes). > This might(!) depend on (or at least benefit from) splitting up the type > analysis phase (as discussed before, looks like we still need a ticket for > this), so that we can recognise the declared/builtin names when running > the transform, and can handle the final return values appropriately (which > are sometimes boolean ints instead of (None) Python objects, for example) > *after* switching to the corresponding C-API function. This is a going to cause at least as much trouble as the new temps (though that is going to be worth it in the end, and so could this). At least myself I am not decided on how I'd like to see such a split -- I know I advocated it a year ago, but now "first names, then expressions" seems a bit suboptimal to me. "First declare possible types, then transform, then resolve and insert coercion nodes and raise any errors" seems promising but I'm still unsure about it. If there's a chance of a Cython workshop during the coming year I'd say these kind of matters (and the actual coding) can be resolved more easily that way. Otherwise it seems to stand between one person with a bright idea doing it all alone, or one of those 100-emails-threads converging very slowly towards the right solution... But I may be overestimating the complexity, if you have a clear idea then I won't object to it. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
