[C++-sig] Loading Boost.Python made bindings is horribly slow?
jdbrandm at unity.ncsu.edu
Fri Apr 2 21:06:18 CEST 2004
Niall Douglas wrote:
>With GCC v3.4 from CVS, I finally have build time down to only nine
>hours now rather than the 20+ it was with GCC v3.3. However, when
>loading the bindings into python on Linux v2.4 kernel it takes well
>over six minutes.
>Is anyone else having this problem? I don't think it's BPL's fault
>really as on Windows it only takes a second or two so I'm guessing
>it's the dynamic linker. I'd imagine that that prebinding linkage
>feature of newer Linuces will fix this problem - in the meantime, any
You most certainly can minimize the exports. The best way to do this is
to segregate all of the classes and functions that you want to share
between modules (python or otherwise) into a separate .so, to be placed
in one of the standard library locations. Then, place all of your
Python export code ( creating class_<>, def, and so on) in the module to
be loaded from Python.
Next, write a symbol map file. The complete specification for these
things is fairly complex, but since you have segregated out all of your
shared stuff, what you need is very simple (see the GNU ld manual for
more). They are vaguely similar (in functionality) to .def files in
Windows. My module defines BOOST_PYTHON_MODULE(cvisual) and the
resulting map file looks like this:
(file named linux-symbols.map)
Now, the only function that is exported is extern "C" initcvisual() and
the resulting cvisual.so file size is very significantly reduced. (from
about 3MB to 1.5 MB for me). You have to add the option
-Wl,--version-script=$(MAPFILE_NAME) to the link command when invoking
the linker via G++ to make use of this file.
More information about the Cplusplus-sig