How to circumvent PYO3's function overhead properly using C functions , especially with magic methods/member functions?

[Cazadorro]

We've done profiling, and came to the same conclusion that these threads have #3827 #1607. While the cost of the boundary isn't super high if we do enough work on the rust side, our use case makes it the bottleneck. We are basically trying to recreate mathematical vector primitive types, like vec2/3/4s, and find that PyO3 can be 4x slower or more in real world cases than PyGLM for the equivalent work. Because PyGLM is also an extension using the C-api, this should be a valid comparison, and something we should be able to accomplish in rust.

What we'd like to do is figure out how to not throw the baby out with the bath water here. We could afford to wait for 0.22 if it was going to come in the next few months, our project is "fresh" so we don't have any weird backwards compatibility constraints, but it looks like even 0.22 is going to have massive slow down compared to PyGLM (going from 4x to 2x performance loss is still not acceptable for us, it needs to be within 10%).

What we'd like to do, is for some functions and [pyclass] member functions, we'd like to just take a unsafe extern "C" fn and do what we need there, with out massively altering the rest of the system or having to write tones of boiler plate elsewhere.

From this issue #3827 we can kind of see how to deal with this for stand alone functions, but I don't understand how we do this for classes. using cargo expand, there's a looot of stuff there, and ideally what we'd like to do is just be able to do something like

[external_pymethod("MyPyClass", "__len__")]
unsafe extern "C" fn fast_len (...){
}

or

#[pymodule]
fn py_module(_py: Python, m: &PyModule) -> PyResult<()> { 
    m.add_class<MyPyClass>()?; 
   //bike shedding
    m.add_external_magic<MyPyClass>("__len__", PyCFunction::internal_new(&FAST_LEN, m.into())?)?;
    Ok(())
}

or something similar to the amount of effort. Is there anyway to do this with out actually just creating the class, cargo expanding, then copy pasting the cargo expansion back and editing the py_methods list there? And how do you properly deal with reference counting etc... using these c functions?

[davidhewitt]

We could afford to wait for 0.22 if it was going to come in the next few months, our project is "fresh" so we don't have any weird backwards compatibility constraints, but it looks like even 0.22 is going to have massive slow down compared to PyGLM (going from 4x to 2x performance loss is still not acceptable for us, it needs to be within 10%).

I'm curious what gave you the expectation is that 0.22 is going to be slow; we're actively working to remove these overheads and I think it's realistic that we should be much better in 0.22 or 0.23 over the coming months.

Our main ideas I'm aware of which will bring the next round of improvements are:

• Lazy-initialize the global reference pool to reduce its overhead when unused #4178
• skip type check of method receivers where unnecessary #4026

---

That said, of course it makes sense that you may really need to drop lower-level. I hope it to be unnecessary in the near future and that's the main reason why I haven't invested any effort in making this easy for PyO3 users.

I would suggest you start by writing a normal #[pymethods] and then use a tool like cargo expand to get the current PyO3 expansion. You should be aware of the following things:

• Panics can't cross into Python so you will need to handle those
• We also have handling for dropping Py<T> without the GIL, though you also have the option of disabling that altogether in 0.22. But if you do not disable and do not handle, you risk memory leaks.

It's these two main tasks (plus argument conversion) that is what the contents of the current expansion are.

For reference counting, you should use Bound::from_owned_ptr and similar to convert pointers (with zero cost) into PyO3's safe API. (See also #3965)