On Wed, Jul 3, 2013 at 8:43 PM, Antony Polukhin
2013/7/3 Andrey Semashev
On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent
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.
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
The setup library is especially big because it contains rather complicated Boost.Spirit parsers for filters and formatters and it instantiates
I did not compare library sizes purposefully, but it is very possible to be there. 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.