Reduce debug symbols size

[Andrey Semashev]

There is ​this discussion on Boost developers mailing list concerning Boost.Log compiled binary sizes. The problem by a large degree is caused by Boost.Spirit generating lots of debug info in the compiled libraries. I came to this conclusion by analyzing the object file sizes of Boost.Log (I've presented the object sizes in ​this post, and you can see that the most part if the libboost_log_setup-vc110-mt-gd-1_55.lib library is occupied by parsers).

The parsers in question are implemented in libs/log/src/filter_parser.cpp and formatter_parser.cpp. I'm not sure if there's anything I can do on Boost.Log side to mitigate the problem, other than to just rewrite them without Boost.Spirit. However, this example and my other general experience with Boost.Spirit indicates that Boost.Spirit tends to generate lots of debug info even for parsers of moderate complexity (like the ones in Boost.Log). I would really like something to be done about this.

[Joel de Guzman]

If you are using Boost.Phoenix, it's a good first step to try to not use it. It is possible to make semantic-action free parsers. Check out the compiler tutorial examples. Expression template libraries are notorious in generating big debug libs with visual studio (not so much with GCC). What I am attempting is to lessen the effects of ET at compile time and by doing so I am also able to reduce the debug output. Work is being done in that direction with Spirit X3. Alas, it's still in development and far from production ready. It has a lot of components already implemented thus far. If you'd want to take an early look and try it out, I'd be happy to assist you.

[Joel de Guzman]

Hartmut also suggested separating the debug info from the code. Normally debug info is stored in separate files (*.pbd).

[Andrey Semashev]

Yes, *.pdb are a possibility but only for shared libraries, which are not much of a problem (the shared library boost_log_setup-vc110-mt-gd-1_55.dll is only around 3 MiB vs. 400 MiB of the static library). It's the static library I'm most concerned.

As for the semantic actions, I used Boost.Bind to implement them, nothing fancy. I suppose, it shouldn't generate that much debug info, but I can try replacing it with hand-written function objects.

By semantic-action free parsers you mean using the attributes? I'm not sure this is applicable to my case because the parsers are supposed to build filters and formatters as they parse the string. Filters and formatters themselves are based on Boost.Phoenix v3 but only phoenix::bind and logical operators are used to compose the filters as the parsers work. I already use type erasure to hide the actual parsed filters and formatters (which are compiled in separate translation units), so there shouldn't be a combinatorial explosion of phoenix::bind instantiations. I could try removing these bits of Boost.Phoenix but I'm not sure it'll help much. But thanks for the suggestion.

Is there an estimate when Spirit X3 is ready? Is it API-compatible with Spirit v2? I could give it a try but I'm most interested in a short-term solution right now (i.e. for 1.55 - 1.56 release).