Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why pybind11 is slower than cython #1227

Closed
zhuoqiang opened this issue Dec 27, 2017 · 2 comments
Closed

why pybind11 is slower than cython #1227

zhuoqiang opened this issue Dec 27, 2017 · 2 comments

Comments

@zhuoqiang
Copy link

simple benchmark for the example add() function

In [1]: import example
In [2]: %timeit example.add(1000, 2000)
606 ns ± 33.5 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

release buidl (using cmake -DCMAKE_BUILD_TYPE=Release .. ) improves the speed:

In [1]: import example
In [2]: %timeit example.add(1000, 2000)
469 ns ± 16.8 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

however, comparing with cython it still not fast enough:

In [10]: %reload_ext cython
In [11]:
    ...: %%cython
    ...: cpdef int cython_add(int a, int b):
    ...:     return a + b
    ...:
In [12]: %timeit cython_add(1000, 2000)
114 ns ± 5.48 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

pybind11 is 4X times slower than cython.

Why that happened? Is there anything to do to improve the performance here?

@aldanor
Copy link
Member

aldanor commented Dec 27, 2017

IIRC, due to all the argument conversion and casting logic in pybind11, Cython will normally be somewhat faster on microbenchmarks which is to be expected.

// Make sure you compile both with the same compiler flags though for the results to be any meaningful.

@daly88
Copy link

daly88 commented Sep 26, 2019

it allocate a std::vector.reserve to store the function argument for each call, which will do malloc/new memory allocation, but it's meaningless

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants