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

Subject: Re: [boost] Extremely large Visual Studio libboost_log_setup* binaries
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-07-13 18:43:06

on Thu Jul 11 2013, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:

> On Thu, Jul 11, 2013 at 12:04 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>>
>> on Wed Jul 03 2013, Eric Niebler <eniebler-AT-boost.org> 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