Boost logo

Boost Users :

Subject: [Boost-users] [boost-users][serialization]Linking time problems with a class hierarchy
From: Laszlo Orban (contiboost_at_[hidden])
Date: 2010-09-10 08:20:19


Currently we are having a class hierarchy consisting of 50+ class
definitions (all descendants of one class) along with some assistant
structures; the typical you would expect from a 'real' application, and this
base is growing each day. We are serializing and deserializing objects from
these classes in a kind of client-server application. Everything works fine
(testing on both linux and windows platform using gcc 4.4.1), however we are
experiencing a rather weird issue. It started quite some time ago, but only
starting to get really annoying nowadays: the compile and linking time of
the projects that uses these classes are starting to get ridiculous and we
could trace this back to serialization. As usual for polymorphic archives,
we are using the BOOST_CLASS_EXPORT_GUID macro for creating the necessary
singletons for the class definitions. To narrow down the problem we have
tried the following checks:

1.) If we comment out all the BOOST_CLASS_EXPORT_GUID macros, the problem is
gone, linking and compiling time is reduced to some seconds, the length of
the executable and the object files are 'normal', but of course the
serialization doesn't work. If I put the macros back, the compiling of the
source file that contains them skyrockets to 2-3 minutes, also the linking
time to around the same time on a Core2Duo 2 GHz machine, and the length of
the object file (and thus the executable) goes from several hundred Kbs to
15+ Mb-s. (A bit varied values on the same code depending if it is linux or
windows, but the same behaviour nonetheless.)

2.) We have tried to mess around with the number of macros running, and it
seems the increase of the compile time is linear, linking time is more like
exponential.

3.) We have tried to 'clean' the class structure and reduced the members in
the classes to only some basic booleans and integers (even purged the
std::string-s), in most classes completely eliminating all members just let
the 'skeleton' there, and still: no significant change in compile and
linking time.

4.) We have tried to do all this is in a 'clean' project with only a "void
main() {}" method and the class hierarchy, to ensure that not somehow the
usage of it causes the problem: negative, the problem still exists.

Now it is not a great problem that the compile is so slow, as that causes a
problem only when the class hierarchy is changed. Also the executable size
is only a bit irritating, but not a serious problem. However the linking
time is something we need to solve asap, as it is hindering our development
a lot, especially as this class hierarchy is used in several applications
(naturally, we wouldn't need serialization otherwise), thus the linking
problem affects all of them. (And this will be worse later, as the class
hierarchy is growing each day.)

Any ideas about how to go on from here? Is there any way I can change the
BOOST_CLASS_EXPORT_GUID macro to a more simple? effective? one? Or maybe all
this is normal and we have to live with it?

(This is a strongly reduced snippet on how we are using the polymorphic
serialization with boost_1_42, but as I mentioned, it is working nicely:
class Mess
{
    private:
        friend class boost::serialization::access;

        template<class Archive>
        void serialize(Archive & ar, const unsigned int version)
        {
            ar & messageId;
        }

    protected:
        int messageId;

    public:
    (...)
};

class CMess : public Mess
{
    private:
        friend class boost::serialization::access;

        template<class Archive>
        void serialize(Archive & ar, const unsigned int version)
        {
            ar & boost::serialization::base_object<Mess>(*this);
            ar & cma;
        }

    protected:
        int cma;
    (...)
};
(...)
BOOST_CLASS_EXPORT_GUID(CMess, "CMess")

Thanks for reading it!



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net