@@ -76,12 +76,33 @@ source code contained in the file ``my_ext.cpp``.
76
76
77
77
.. code-block :: cmake
78
78
79
- nanobind_add_module(my_ext my_ext.cpp)
79
+ nanobind_add_module(my_ext my_ext.cpp)
80
80
81
81
:cmake:command: `nanobind_add_module ` resembles standard CMake commands like
82
82
``add_executable() `` and ``add_library() ``. Any number of source code and
83
83
header files can be declared when the extension is more complex and spread out
84
84
over multiple files.
85
85
86
+ .. note ::
87
+
88
+ One opinionated choice of :cmake:command: `nanobind_add_module ` is that it
89
+ optimizes the *size * of the extension by default (i.e., ``-Os `` is passed to
90
+ the compiler regardless of the project-wide settings). You must specify the
91
+ ``NOMINSIZE `` parameter to the command to disable this behavior and, e.g.,
92
+ optimize extension code for speed (i.e., ``-O3 ``):
93
+
94
+ .. code-block :: cmake
95
+
96
+ nanobind_add_module(my_ext NOMINSIZE my_ext.cpp)
97
+
98
+ The default is chosen this way since extension code usually wraps existing
99
+ C++ libraries, in which the main computation takes place. Optimizing the
100
+ bindings for speed does not measurably improve performance, but it does make
101
+ the bindings *significantly * larger.
102
+
103
+ If you observe slowdowns when porting a pybind11 extension, or if your
104
+ extension performs significant amounts of work within the binding layer,
105
+ then you may want to experiment with passing the ``NOMINSIZE `` parameter.
106
+
86
107
The :ref: `next section <basics >` will review the contents of example module
87
108
implementation in ``my_ext.cpp ``.
0 commit comments