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 16:27:41

On Wed, Jul 3, 2013 at 11:07 PM, Tom Kent <lists_at_[hidden]> wrote:

> On Wed, Jul 3, 2013 at 12:11 PM, Andrey Semashev
> <andrey.semashev_at_[hidden]>wrote:
>
> >
> > Also, compare apples to apples. The OP mentions the space needed to build
> > Boost, not the size of the actual binaries you get.
> >
> >
> I was referring to the actual binaries that you get, I didn't even look at
> the space needed to build. The reason I noticed this is because the Windows
> binaries that I publish for public consumption doubled in size with this
> release.
>

Oh, I misinterpreted your message then, sorry.

> I had already received comments that the boost binaries were too big, I'm
> seriously worried that this further increase will negatively impact usage
> of the entire boost library.
>

Well, you will face this problem sooner or later, since Boost is growing
constantly. I think, eventually installer will have to get modularized,
much like Boost itself is getting now.

That doesn't mean I don't want to reduce Boost.Log binary size.

> 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.
>
> Maybe we need to look at making these the defaults. What do you mean by
> "parsers" in this context, is this a core functionality of log? Sorry if
> these are dumb questions, I haven't had a good excuse to dive into the log
> library yet.
>

No, nothing from boost_log_setup is core functionality. In fact, large
binary size and optionality of that code was the reason why I separated it
to another library.

Aside from logging itself, Boost.Log provides support for reading logging
configuration from files or streams. For the most part this consists of 3
parsers: filter parser, formatter parser and settings parser. The former
two can be used as standalone components, without connection to the
settings parser. So you basically can pass a string to the library and it
returns a filter/formatter that you can call and use with the rest of the
library. Now, these 3 parsers use Boost.Spirit and this makes them have
lots of debug info, which makes them so large (see my reply to Antony in
this thread). The problem worsens with the fact that the parsers are built
both for char and wchar_t by default.

One other part of boost_log_setup that takes space is the default
filter/formatter factories that are instantiated for all fundamental types.
These factories are invoked by the parsers to actually create the filters
and formatters. Without them the user has to register every single
attribute in the library (both filter and formatter factory), which would
make it very inconvenient to use. Right now users only have to register
their custom typed attributes.

Anyway, this last part (default factories) I can make optional, and I think
this will reduce binary size considerably. However, I don't think this can
be done for 1.54. Regarding parsers though, I'm not sure there's anything I
can do, but if I'd appreciate if any Boost.Spirit/Boost.Phoenix gurus would
take a look at them and suggest how to tweak them.

Regarding the build defaults, by default the library builds in its maximum
configuration. I.e. it should just work by default. If you want to optimize
(like, reduce binary size), you should disable the things you don't need. I
believe this is the right approach and it allows to avoid puzzling users
with unnecessary problems. Library configuration is described here:

http://www.boost.org/doc/libs/1_54_0/libs/log/doc/html/log/installation/config.html