blob: 3659197568de0d70e5d5751d689d48aea38dbaf7 [file] [log] [blame]
Wenzel Jakob5cd33112015-10-20 00:58:59 +02001Benchmark
2=========
3
4The following is the result of a synthetic benchmark comparing both compilation
5time and module size of pybind11 against Boost.Python.
6
Wenzel Jakob66c9a402016-01-17 22:36:36 +01007Setup
8-----
9
10A python script (see the ``docs/benchmark.py`` file) was used to generate a set
11of files with dummy classes whose count increases for each successive benchmark
12(between 1 and 2048 classes in powers of two). Each class has four methods with
Wenzel Jakob5cd33112015-10-20 00:58:59 +020013a randomly generated signature with a return value and four arguments. (There
14was no particular reason for this setup other than the desire to generate many
15unique function signatures whose count could be controlled in a simple way.)
16
17Here is an example of the binding code for one class:
18
19.. code-block:: cpp
20
21 ...
22 class cl034 {
23 public:
24 cl279 *fn_000(cl084 *, cl057 *, cl065 *, cl042 *);
25 cl025 *fn_001(cl098 *, cl262 *, cl414 *, cl121 *);
26 cl085 *fn_002(cl445 *, cl297 *, cl145 *, cl421 *);
27 cl470 *fn_003(cl200 *, cl323 *, cl332 *, cl492 *);
28 };
29 ...
30
31 PYBIND11_PLUGIN(example) {
32 py::module m("example");
33 ...
34 py::class_<cl034>(m, "cl034")
35 .def("fn_000", &cl034::fn_000)
36 .def("fn_001", &cl034::fn_001)
37 .def("fn_002", &cl034::fn_002)
38 .def("fn_003", &cl034::fn_003)
39 ...
40 return m.ptr();
41 }
42
43The Boost.Python version looks almost identical except that a return value
44policy had to be specified as an argument to ``def()``. For both libraries,
45compilation was done with
46
47.. code-block:: bash
48
Wenzel Jakob66c9a402016-01-17 22:36:36 +010049 Apple LLVM version 7.0.2 (clang-700.1.81)
Wenzel Jakob5cd33112015-10-20 00:58:59 +020050
51and the following compilation flags
52
53.. code-block:: bash
54
Wenzel Jakob66c9a402016-01-17 22:36:36 +010055 g++ -Os -shared -rdynamic -undefined dynamic_lookup -fvisibility=hidden -std=c++14
56
57Compilation time
58----------------
Wenzel Jakob5cd33112015-10-20 00:58:59 +020059
60The following log-log plot shows how the compilation time grows for an
Wenzel Jakob66c9a402016-01-17 22:36:36 +010061increasing number of class and function declarations. pybind11 includes many
62fewer headers, which initially leads to shorter compilation times, but the
63performance is ultimately fairly similar (pybind11 is 19.8 seconds faster for
64the largest largest file with 2048 classes and a total of 8192 methods -- a
65modest **1.2x** speedup relative to Boost.Python, which required 116.35
66seconds).
Wenzel Jakob5cd33112015-10-20 00:58:59 +020067
Wenzel Jakobf64feaf2016-04-28 14:33:45 +020068.. only:: not latex
69
70 .. image:: pybind11_vs_boost_python1.svg
71
72.. only:: latex
73
74 .. image:: pybind11_vs_boost_python1.png
Wenzel Jakob5cd33112015-10-20 00:58:59 +020075
Wenzel Jakob66c9a402016-01-17 22:36:36 +010076Module size
77-----------
78
79Differences between the two libraries become much more pronounced when
80considering the file size of the generated Python plugin: for the largest file,
81the binary generated by Boost.Python required 16.8 MiB, which was **2.17
82times** / **9.1 megabytes** larger than the output generated by pybind11. For
83very small inputs, Boost.Python has an edge in the plot below -- however, note
84that it stores many definitions in an external library, whose size was not
85included here, hence the comparison is slightly shifted in Boost.Python's
86favor.
Wenzel Jakob5cd33112015-10-20 00:58:59 +020087
Wenzel Jakobf64feaf2016-04-28 14:33:45 +020088.. only:: not latex
89
90 .. image:: pybind11_vs_boost_python2.svg
91
92.. only:: latex
93
94 .. image:: pybind11_vs_boost_python2.png
95
Wenzel Jakob5cd33112015-10-20 00:58:59 +020096