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

Subject: Re: [boost] Extremely large Visual Studio libboost_log_setup* binaries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-07-03 13:04:09

On Wed, Jul 3, 2013 at 8:43 PM, Antony Polukhin <antoshkka_at_[hidden]> wrote:

> 2013/7/3 Andrey Semashev <andrey.semashev_at_[hidden]>
>
> > > > On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent <lists_at_[hidden]> wrote:
> > <...>
> > > > > example the msvc-8.0-64 build went from 2GB to 5GB. Upon further
> >
>
> Linux kernel binaries weight 2mb, Firefox binaries weight ~100mb. Libraries
> of Boost.Log weight  ~3GB.
>

Strip the binaries and compare then.

>  I did not compare library sizes purposefully, but it is very possible to
> be
> > the case. If you build the complete version of the library, the resulting
> > binaries are expected to be large. Someone else asked me a similar
> question
> > on the SF, and the answer is, well, because there is lots of code in
> there.
> > The setup library is especially big because it contains rather
> complicated
> > Boost.Spirit parsers for filters and formatters and it instantiates
> parsed
> > filters and formatters for all fundamental types. Multiply that by the
> > number of character types the library supports.
>
>
> Those are lame excuses. Remove duplicated code (a big part of Boost.Log is
> a reinvented Boost.Thread). Do not generate so many parsers (type
> erasure?).
>

Those are bold statements, you know, and moreover absolutely irrelevant. I
have described where the extra size comes from, none of which is related to
the "duplicated" code (which is not duplicated, as I have described in
another ticket to you). If you have solid grounds to prove me wrong then
please go ahead present your data. I'm not interested in speculations.

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

Right now I don't see what can be done about it without affecting the
library functionality. Well, I could drop Boost.Spirit and Boost.Phoenix to
reduce the amount of debug symbols, but I'm not inclined to do that since
the code will become much less maintainable. Oh, and it will add some more
"duplicated" code, right?

The user can disable portions of the library he doesn't need by defining
config macros. E.g. disabling wchar_t support can reduce the size by
approximately 50%. Disabling parsers altogether will make boost_log_setup*
practically empty.