PyDict.set_item is very slow.

[songww]

Bug Description

It is slower than pure python.

Steps to Reproduce

1. maturin new -b pyo3 --mixed rdict
2. create venv python -m venv .venv --system-site-packages
3. wrote code

use pyo3::prelude::*;

#[pyfunction]
fn setitems(py: Python<'_>) -> PyResult<()> {
    let d = pyo3::types::PyDict::new(py);
    d.set_item("hello", "there").unwrap();
    d.set_item("use std::", "hello").unwrap();
    Ok(())
}

/// A Python module implemented in Rust.
#[pymodule]
fn rdict(_py: Python, m: &PyModule) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(setitems, m)?)?;
    Ok(())
}

4. enable lto for release build.

[profile.release]
lto = true
codegen-units = 1
opt-level = 3

5. compile and measure it.

Backtrace

no

Your operating system and version

Debian testing

Your Python version (python --version)

Package: python3.10 Version: 3.10.4-2

Your Rust version (rustc --version)

rustc 1.61.0-nightly (ee915c34e 2022-03-28)

Your PyO3 version

v0.16.2

How did you install python? Did you use a virtualenv?

Installed apt
using venv

Additional Info

no

[mejrs]

This discrepancy is because I think your Python function reuses the strings, while the pyo3 function creates new strings for every call.

In fact, if you store the strings in a static, you can avoid that. Something like

macro_rules! intern {
    ($py: expr, $text: literal) => {{
        static INTERNED: GILOnceCell<Py<PyString>> = GILOnceCell::new();

        INTERNED.get_or_init($py, || {            
                PyString::new($py, $text).into()         
            }).as_ref($py)
    }}
}

#[pyfunction]
fn setitems_cached(py: Python<'_>) -> PyResult<()> {
    let d = pyo3::types::PyDict::new(py);
    d.set_item(intern!(py, "hello"), intern!(py, "there"))?;
    d.set_item(intern!(py, "there"), intern!(py, "hello"))?;
    Ok(())
}

beats the Python function in my benchmark.

[adamreichold]

Opened #2268 adding PyString::intern. What is a bit funny IMHO, is that the interning seems to be implemented using a PyDict, i.e. using this API would trade an additional dictionary look-up against the allocation. Which is probably also why there is no PyUnicode_InternFromStringAndSize because PyDict_GetItemString requires a null-terminated string.

[adamreichold]

Or put differently, I wonder whether exposing PyDict_{Get,Set}ItemString would be a more efficient even though less general addition resolving the same issue.

[adamreichold]

After looking into the implementation of PyDict_{Set,Get}ItemString, these also unconditionally allocate a temporary PyUnicode object and are only considered compatibility shims, not optimizations. Hence, I think that PyUnicode_InternFromString is not useful in this case at all as it will always allocate a PyUnicode object as well and add the dictionary look-up on top.

Hence one must use other interning techniques like the one initially proposed by @mejrs. What do you think about adding a more generic version of that intern! for arbitrary PyObject instances to PyO3 to make the idiom more approachable?

[adamreichold]

@songww PyO3 version 0.16.3 released today does include the intern! macro which should be able to fix the performance issue you observed.

[songww]

thanks