introduce trampolines for methods

[davidhewitt]

This is a refactoring to the generated #[pyfunction] and #[pymethods] with the intention of reducing compile time and binary size.

The motivation for the change is that cargo llvm-lines currently reports many monomorphizations of std::panicking::try::do_call and friends being instantiated - in fact, it's one per #[pyfunction] and every method in #[pymethods], which is quite a lot of instantiations.

The change follows a similar idea to #2478 changing extract_argument to make use of "dynamic dispatch". Here, we create "trampoline" wrappers for all possible C-API function pointers we expose to Python. These wrappers take a function pointer to the real implementation of the function in question, and call it after starting the std::panic::catch_unwind machiner and creating a GILPool.

Much like in #2704 I suspect LLVM can do a pretty good job at optimizing out the dynamic dispatch. I saw no change at all in benchmarks for the pytests crate. So overall I believe this should have a compile-time win with little-to-no impact on runtime performance.

For our pytests crate I get a 10% reduction in cargo llvm-lines count, and for real-world use cases potentially with many small function wrappers (e.g. getters / setters) I suspect the reduction could be even greater.

Detail-wise, for some method MyClass::foo, the generated code change from a single C-ABI symbol:

unsafe extern "C" fn __pymethod_foo__(
    slf: *mut ffi::PyObject,
    args: *const *mut ffi::PyObject,
    nargs: ffi::Py_ssize_t,
    kwnames: *mut ffi::PyObject,
) -> *mut ffi::PyObject {
    let gil = GILPool::new();
    let py = gil.python();
    pyo3::callback::panic_result_into_callback_output(
        py,
        panic::catch_unwind(move || -> PyResult<_> {
            /* implementation */
        }),
    )
}

to an C-ABI symbol which just calls the trampoline wrapper with a pointer to the actual implementation.

unsafe extern "C" fn trampoline(
    slf: *mut ffi::PyObject,
    args: *const *mut ffi::PyObject,
    nargs: ffi::Py_ssize_t,
    kwnames: *mut ffi::PyObject,
) -> *mut ffi::PyObject
{
    impl_::trampoline::fastcall_with_keywords(
        slf,
        args,
        nargs,
        kwnames,
        MyClass::__pymethod_foo__,
    )
}
unsafe fn __pymethod_foo__<'py>(
    py: Python<'py>,
    slf: *mut ffi::PyObject,
    args: *const *mut ffi::PyObject,
    nargs: ffi::Py_ssize_t,
    kwnames: *mut ffi::PyObject,
) -> PyResult<*mut ffi::PyObject> {
    /* implementation */
}

[adamreichold]

It is not really related, but I had a look while reviewing: Doesn't panic_result_into_callback_output need a PanicTrap as well since PanicException::from_panic_payload drops the payload which could make a panic in its Drop impl reach the FFI boundary?

[adamreichold]

Great code bloat reduction! A nit and an unrelated question, but this looks good to me.

[davidhewitt]

It is not really related, but I had a look while reviewing: Doesn't panic_result_into_callback_output need a PanicTrap as well since PanicException::from_panic_payload drops the payload which could make a panic in its Drop impl reach the FFI boundary?

Ahh, yes, when working on PanicTrap was one of the moments when I was thinking a refactor like this could be in order... Then I forgot to install a PanicTrap here. Let me push 😆

[birkenfeld]

Would be cool not to have to repeat the (almost) identical signature here and in the trampoline fn. But the required macro trickery isn't worth it, likely?

[davidhewitt]

I agree with this, however I'd like to defer it to a follow-up PR sometime (there's a fair bit of refactoring which could improve the macro code, and I'd like it not to distract readers of this PR from the behavioural change).