[Cython] Bindings performance issue

[Vitja Makarov]

2011/6/2 Robert Bradshaw <robertwb at math.washington.edu>:
> On Wed, Jun 1, 2011 at 7:26 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> 2011/6/1 mark florisson <markflorisson88 at gmail.com>:
>>> On 31 May 2011 20:25, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>>> Hi!
>>>>
>>>> Is bindings performance issue valuable?
>>>>
>>>> $ cat bindbench.pyx
>>>> def wo_bindings():
>>>>    pass
>>>>
>>>> def outer():
>>>>    def inner():
>>>>        pass
>>>>    return inner
>>>> with_bindings = outer()
>>>>
>>>> $ python
>>>>>>> import timeit
>>>>>>> timeit.repeat('with_bindings()', setup='from bindbench import wo_bindings, with_bindings', repeat=1, number=100000000)
>>>> [6.169871807098389]
>>>>>>> timeit.repeat('wo_bindings()', setup='from bindbench import wo_bindings, with_bindings', repeat=1, number=100000000)
>>>> [4.609416961669922]
>>>>
>>>> PyCBindings makes it 1.3 (difference is about 15ns on my laptop) times
>>>> slower for CPython interpreter execution.
>>>> As CPython has some optimizations for CFunctions and PyCFunctions.
>>>>
>>>> Does it make sense for us? Or we can easily switch to bindings?
>>>>
>>>> --
>>>> vitja.
>>>> _______________________________________________
>>>> cython-devel mailing list
>>>> cython-devel at python.org
>>>> http://mail.python.org/mailman/listinfo/cython-devel
>>>>
>>>
>>> I think switching should be fine, if you'd desperately need the speed
>>> you'd be calling c(p)def functions from Cython. In fact, when the
>>> fused cfunction will be ready it will be even slightly slower, as it
>>> overrides the tp_call. But perhaps that should really be made into a
>>> subclass...
>
> Yes, this should be a subclass, slowing all calls down is a bad idea.
>
>>> Anyway, would you use these for Python classes and module-level def
>>> functions (and closures) only, or would you also use them in extension
>>> classes? Because I found at least a bit of problem there, as extension
>>> class methods get 'self' passed as the first argument to the C
>>> function (as PyCFunctionObject.m_self), whereas methods in Python
>>> classes get 'self' passed in the args tuple (and the m_self is
>>> unused).
>>>
>>
>> Recently I've found a problem with static methods (__new__ for
>> example) of inner classes (classes created inside a function, for
>> instance)
>> I think binding version should be used for all regular def functions
>> (defs, staticmethods, classmethods and so on).
>
> +1 to moving that way. (Well, static and class methods bind
> differently, right?)
>
>> I also think that it's better to rename binding_PyCFunction_Type to
>> something like CyFunctionType and make it more like PyFunction.
>
> +1
>
> Is there any advantage to the method descriptors (other than that
> they're easier for a human to write?)

Initially bindings was written to support bound class methods (am I right?)
So when we use it for regular functions 'binding' in the name doesn't
reflect its purpose.

One the other hand it's much more easy to write manually.

About staticmethods: I think that CyFunction type should handle it as well
because staticmethods can have custom attributes and act just like
normal def one.

The difference is insde descr_get it should return bound method for
normal and self for staticmethods.

Here I've tried to support staticmethods inside bindings type:
https://github.com/vitek/cython/commit/c0725ab340a8173d8e6724c62be3a135df58980e

>
> I think that small speed regression for better compatibility is OK if
> we add a directive to not create binding functions. (It'd be nice if
> we could work around it, but that's hard as CPython has special
> hooks...) The bigger issue is that the binding behavior is backwards
> incompatible, and perhaps in a subtle way. Perhaps we need to have a
> phase where all currently non-binding functions that will become
> binding functions will raise an error (or at least a warning) to wean
> people off of the old behavior before making a switch.
>

Is the difference so significant?

-- 
vitja.