Re: [boost] Extremely large Visual Studio libboost_log_setup* binaries

on Thu Jul 11 2013, Andrey Semashev wrote:

On Thu, Jul 11, 2013 at 12:04 PM, Dave Abrahams wrote:

...

on Wed Jul 03 2013, Eric Niebler wrote:

...

...

Remove duplicated code (a big part of Boost.Log is a reinvented Boost.Thread). Do not generate so many parsers (type erasure?).

Created a ticket #8773 (https://svn.boost.org/trac/boost/ticket/8773)

If Boost.Log is truly that large, I agree with the OP that it's a problem. An effort should be made to bring the size down to something reasonable.

A possibility not previously mentioned: putting more code in headers/templates, so it is instantiated only as needed.

But this will move the excessive binary size to the user's code + increase user's code compile times.

Not if the user is only exploiting a small fraction of the what goes into that huge library.

IMHO, from the user's standpoint this is worse than having a large library to link with.

Which user? It's a tradeoff, and some people will want a different balance than you've provided.

I admit that when there are many optional components which may or may not be used in the user's code (like in Boost.Spirit, for example), this approach is beneficial because it is unrealistic to pre-compile all possible combinations of the components. But in case of Boost.Log the parsers are self-contained, so the user cannot pick some parts of them and reduce the size that way. Selecting character types to instantiate parsers on is possible, but even for a single character type the resulting binary size is considerable.

Still, if you could cut the binary size substantially by doing that, maybe you should consider it. -- Dave Abrahams