[C++-sig] Loading Boost.Python made bindings is horribly slow?

Jonathan Brandmeyer 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 
>suggestions?
>
>  
>
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)
{
        global:
                initcvisual;
        local:
                *;
};

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.

HTH,
Jonathan Brandmeyer






More information about the Cplusplus-sig mailing list