Extremely large Visual Studio libboost_log_setup* binaries
In the 1.54.0 release, I noticed that the size of the binaries built with visual studio was more than twice that of the previous releases. For example the msvc-8.0-64 build went from 2GB to 5GB. Upon further investigation, almost all of that increase was in the libboost_log_setup* binaries, which were each in the 100s of MBs. Does anyone know if there is a reason for this? Is it a configuration error? Tom Kent
On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent <lists@teeks99.com> wrote:
In the 1.54.0 release, I noticed that the size of the binaries built with visual studio was more than twice that of the previous releases. For example the msvc-8.0-64 build went from 2GB to 5GB. Upon further investigation, almost all of that increase was in the libboost_log_setup* binaries, which were each in the 100s of MBs.
Does anyone know if there is a reason for this? Is it a configuration error?
Yes, these libraries are expected to be quite large, especially when debug symbols are on.
We're not talking about a bit bigger, these are bigger than all the rest put together. On Tue, Jul 2, 2013 at 8:32 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent <lists@teeks99.com> wrote:
In the 1.54.0 release, I noticed that the size of the binaries built with visual studio was more than twice that of the previous releases. For example the msvc-8.0-64 build went from 2GB to 5GB. Upon further investigation, almost all of that increase was in the libboost_log_setup* binaries, which were each in the 100s of MBs.
Does anyone know if there is a reason for this? Is it a configuration error?
Yes, these libraries are expected to be quite large, especially when debug symbols are on.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Jul 3, 2013 at 7:28 PM, Tom Kent <lists@teeks99.com> wrote:
On Tue, Jul 2, 2013 at 8:32 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent <lists@teeks99.com> wrote:
In the 1.54.0 release, I noticed that the size of the binaries built with visual studio was more than twice that of the previous releases. For example the msvc-8.0-64 build went from 2GB to 5GB. Upon further investigation, almost all of that increase was in the libboost_log_setup* binaries, which were each in the 100s of MBs.
Does anyone know if there is a reason for this? Is it a configuration error?
Yes, these libraries are expected to be quite large, especially when debug symbols are on.
We're not talking about a bit bigger, these are bigger than all the rest put together.
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.
2013/7/3 Andrey Semashev <andrey.semashev@gmail.com>
On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent <lists@teeks99.com> 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. 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?). Created a ticket #8773 (https://svn.boost.org/trac/boost/ticket/8773) -- Best regards, Antony Polukhin
On 7/3/2013 9:43 AM, Antony Polukhin wrote:
2013/7/3 Andrey Semashev <andrey.semashev@gmail.com>
On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent <lists@teeks99.com> 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.
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.
I understand your frustration, but please be respectful.
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. -- Eric Niebler Boost.org http://www.boost.org
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. -- Dave Abrahams
On Thu, Jul 11, 2013 at 12:04 PM, Dave Abrahams <dave@boostpro.com> 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. IMHO, from the user's standpoint this is worse than having a large library to link with. 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.
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@boostpro.com> 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
On Wed, Jul 3, 2013 at 8:43 PM, Antony Polukhin <antoshkka@gmail.com> wrote:
2013/7/3 Andrey Semashev <andrey.semashev@gmail.com>
On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent <lists@teeks99.com> 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.
On Wed, Jul 3, 2013 at 9:04 PM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
On Wed, Jul 3, 2013 at 8:43 PM, Antony Polukhin <antoshkka@gmail.com>wrote:
2013/7/3 Andrey Semashev <andrey.semashev@gmail.com>
On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent <lists@teeks99.com> 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.
Also, compare apples to apples. The OP mentions the space needed to build Boost, not the size of the actual binaries you get.
On 7/3/2013 1:11 PM, Andrey Semashev wrote:
On Wed, Jul 3, 2013 at 9:04 PM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
On Wed, Jul 3, 2013 at 8:43 PM, Antony Polukhin <antoshkka@gmail.com>wrote:
2013/7/3 Andrey Semashev <andrey.semashev@gmail.com>
On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent <lists@teeks99.com> 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.
Also, compare apples to apples. The OP mentions the space needed to build Boost, not the size of the actual binaries you get.
FYI: QtWebkit as static lib: ~1.3GB Jeff
On Wed, Jul 3, 2013 at 9:36 PM, Jeff Flinn <Jeffrey.Flinn@gmail.com> wrote:
On 7/3/2013 1:11 PM, Andrey Semashev wrote:
On Wed, Jul 3, 2013 at 9:04 PM, Andrey Semashev <andrey.semashev@gmail.com>**wrote:
On Wed, Jul 3, 2013 at 8:43 PM, Antony Polukhin <antoshkka@gmail.com
wrote:
2013/7/3 Andrey Semashev <andrey.semashev@gmail.com>
On Tue, Jul 2, 2013 at 4:47 PM, Tom Kent <lists@teeks99.com> 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.
Also, compare apples to apples. The OP mentions the space needed to build Boost, not the size of the actual binaries you get.
FYI: QtWebkit as static lib: ~1.3GB
For sake of reference I just compiled trunk version (practically the same as 1.54) with VC11 x64: 638 464 boost_log-vc110-mt-1_55.dll 254 468 boost_log-vc110-mt-1_55.lib 1 656 320 boost_log-vc110-mt-gd-1_55.dll 255 704 boost_log-vc110-mt-gd-1_55.lib 1 410 048 boost_log_setup-vc110-mt-1_55.dll 24 566 boost_log_setup-vc110-mt-1_55.lib 4 799 488 boost_log_setup-vc110-mt-gd-1_55.dll 24 742 boost_log_setup-vc110-mt-gd-1_55.lib 22 628 438 libboost_log-vc110-mt-1_55.lib 74 337 686 libboost_log-vc110-mt-gd-1_55.lib 162 812 450 libboost_log_setup-vc110-mt-1_55.lib 434 984 284 libboost_log_setup-vc110-mt-gd-1_55.lib By default dlls are built with embedded debug symbols. I'm sure you can reduce them even more if you build with pdb. This won't work with static libs though.
I'm using static build only so I can provide some data too. I compiled yesterday Boost 1.54 (from svn tag) with VS2012 Update 3. I compiled in both 32 and 64 bit. Build script: call bootstrap.bat call b2 --prefix=. --buid-type=complete toolset=msvc-10.0 architecture=x86 install call b2 --prefix=. --buid-type=complete --libdir=./lib/x64 toolset=msvc-10.0 architecture=x86 address-model=64 install 32 bit: libboost_log_setup-vc110-mt-1_54.lib 143,174 kb libboost_log_setup-vc110-mt-gd-1_54.lib 163,991 kb libboost_log-vc110-mt-1_54.lib 18,213 kb libboost_log-vc110-mt-gd-1_54.lib 61,590 kb 64 bit: libboost_log_setup-vc110-mt-1_54.lib 159,025 kb libboost_log_setup-vc110-mt-gd-1_54.lib 424,702 kb libboost_log-vc110-mt-1_54.lib 22,091 kb libboost_log-vc110-mt-gd-1_54.lib 75,565 kb However, in the application where I use boost.log, I have only one cpp file including a boost.log header (it setup the logging system then I provide my own logging functions to the rest of the system). That cpp file is part of a dll which is currently under 700kb (with boost.log statically linked). One other thing to note is that I define BOOST_LOG_USE_CHAR in that cpp before including log so it might help. All in all, I don't see the problem mentionned but because of my use I suspect that there might be a problem if you try to include some boost log headers in all cpp files, it might generate too much code. However I'm not sure at all of that. Maybe a basic test to check user binary growth when using only boost.log headers might provide more information. Joel Lamotte
On Wed, Jul 3, 2013 at 10:00 PM, Klaim - Joël Lamotte <mjklaim@gmail.com>wrote:
However, in the application where I use boost.log, I have only one cpp file including a boost.log header (it setup the logging system then I provide my own logging functions to the rest of the system).
Sorry, I meant 1 cpp file including 11 boost log headers and more.
On Wed, Jul 3, 2013 at 12:11 PM, Andrey Semashev <andrey.semashev@gmail.com>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. 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.
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. Tom
On Wed, Jul 3, 2013 at 11:07 PM, Tom Kent <lists@teeks99.com> wrote:
On Wed, Jul 3, 2013 at 12:11 PM, Andrey Semashev <andrey.semashev@gmail.com>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/conf...
On Thursday 04 July 2013 00:27:41 you wrote:
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.
I've made a commit that implements this in trunk. Disabling default factories reduces the debug static lib size to 296 MiB: 663552 Jul 14 16:02 boost_log_setup-vc110-mt-1_55.dll 24566 Jul 14 16:02 boost_log_setup-vc110-mt-1_55.lib 2462208 Jul 14 16:02 boost_log_setup-vc110-mt-gd-1_55.dll 24742 Jul 14 16:02 boost_log_setup-vc110-mt-gd-1_55.lib 638464 Jul 14 16:02 boost_log-vc110-mt-1_55.dll 254468 Jul 14 16:02 boost_log-vc110-mt-1_55.lib 1656832 Jul 14 16:02 boost_log-vc110-mt-gd-1_55.dll 255704 Jul 14 16:02 boost_log-vc110-mt-gd-1_55.lib 112617054 Jul 14 16:01 libboost_log_setup-vc110-mt-1_55.lib 311247848 Jul 14 16:02 libboost_log_setup-vc110-mt-gd-1_55.lib 22629340 Jul 14 16:01 libboost_log-vc110-mt-1_55.lib 74343412 Jul 14 16:02 libboost_log-vc110-mt-gd-1_55.lib Not much of an improvement, I guess.
2013/7/3 Andrey Semashev <andrey.semashev@gmail.com>
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.
I'll just explain what confuses me: * Stripped logger library is bigger than any other Boost library. * Logger library contains implementation of call_once, thread local storage, atomics, nonblocking queues... IMO it is not the right place for that functionality. It must be merged with Boost.Thread, Boost.Atomic and other Boost libraries if Boost.Log implementation is better. * Non-stripped Boost.Log bloats binary installer *much* more than any other Boost library. If none of that rings a bell, then I'm slightly insane and totally wrong => I'm sorry. But otherwise please address those issues and fix them. -- Best regards, Antony Polukhin
* Logger library contains implementation of call_once, thread local storage, atomics, nonblocking queues... IMO it is not the right place for that functionality. It must be merged with Boost.Thread, Boost.Atomic and other Boost libraries if Boost.Log implementation is better.
i cannot comment on a lot of these claims, but andrey is actually co-maintainer of boost.atomic and did some significant contributions. tim
On Wed, Jul 3, 2013 at 10:18 PM, Antony Polukhin <antoshkka@gmail.com>wrote:
I'll just explain what confuses me: * Stripped logger library is bigger than any other Boost library.
So what?
* Logger library contains implementation of call_once, thread local storage, atomics, nonblocking queues... IMO it is not the right place for that functionality. It must be merged with Boost.Thread, Boost.Atomic and other Boost libraries if Boost.Log implementation is better.
Ok, let's see how much space they take. This is what the static debug libs consist of: libboost_log-vc110-mt-gd-1_55.lib: 1 445 620 attribute_name.obj 822 355 attribute_set.obj 894 604 attribute_value_set.obj 706 555 code_conversion.obj 1 859 847 core.obj 3 613 753 date_time_format_parser.obj 555 378 debug_output_backend.obj 570 930 default_attribute_names.obj 1 663 193 default_sink.obj 424 925 dump.obj 420 758 dump_avx2.obj 415 277 dump_ssse3.obj 621 148 event.obj 5 543 958 event_log_backend.obj 2 749 488 exceptions.obj 5 136 624 format_parser.obj 1 646 009 global_logger_storage.obj 1 315 975 light_rw_mutex.obj 988 729 named_scope.obj 5 128 769 named_scope_format_parser.obj 1 713 509 once_block.obj 555 737 process_id.obj 751 919 process_name.obj 1 593 922 record_ostream.obj 1 273 079 severity_level.obj 180 simple_event_log_res.obj 1 969 074 spirit_encoding.obj 3 039 412 syslog_backend.obj 15 313 056 text_file_backend.obj 1 182 865 text_ostream_backend.obj 575 528 threadsafe_queue.obj 1 244 833 thread_id.obj 556 962 thread_specific.obj 764 713 timer.obj 57 159 timestamp.obj 1 207 578 trivial.obj 34 667 unhandled_exception_count.obj libboost_log_setup-vc110-mt-gd-1_55.lib: 84 880 092 default_filter_factory.obj 78 733 860 filter_parser.obj 92 323 500 formatter_parser.obj 39 735 808 init_from_settings.obj 2 109 440 init_from_stream.obj 777 225 parser_utils.obj 54 887 842 settings_parser.obj The components you listed are in once_block.obj, threadsafe_queue.obj, thread_specific.obj. Still think that these are the culprit? I suggest you get slightly more informed next time before you start pointing fingers. BTW, if anyone's interested, I've described the reasoning for implementing some of these components here: https://svn.boost.org/trac/boost/ticket/8730#comment:9 * Non-stripped Boost.Log bloats binary installer *much* more than any other
Boost library.
Although I don't aim to minimize the binary size, that's something I'd like to address, if possible.
2013/7/3 Andrey Semashev <andrey.semashev@gmail.com>
On Wed, Jul 3, 2013 at 10:18 PM, Antony Polukhin <antoshkka@gmail.com
wrote:
I'll just explain what confuses me: * Stripped logger library is bigger than any other Boost library.
So what?
Support library for logging is bigger than other libraries (including wave and serialization). You think that it is OK?
* Logger library contains implementation of call_once, thread local storage, atomics, nonblocking queues... IMO it is not the right place for that functionality. It must be merged with Boost.Thread, Boost.Atomic and other Boost libraries if Boost.Log implementation is better.
Ok, let's see how much space they take. This is what the static debug libs consist of:
<...> Do not mix chops and flies. Binaries size and duplicate functionality are different points. Do I really need to explain why duplicating code/functionality is bad?
* Non-stripped Boost.Log bloats binary installer *much* more than any other
Boost library.
Although I don't aim to minimize the binary size, that's something I'd like to address, if possible.
Thank you. I'd love to see those changes! -- Best regards, Antony Polukhin
On Thu, Jul 4, 2013 at 9:27 AM, Antony Polukhin <antoshkka@gmail.com> wrote:
2013/7/3 Andrey Semashev <andrey.semashev@gmail.com>
On Wed, Jul 3, 2013 at 10:18 PM, Antony Polukhin <antoshkka@gmail.com
wrote:
I'll just explain what confuses me: * Stripped logger library is bigger than any other Boost library.
So what?
Support library for logging is bigger than other libraries (including wave and serialization). You think that it is OK?
I don't see anything wrong with it. As well as I don't see the point in comparing their sizes, unless you have specific requirements. Do not mix chops and flies. Binaries size and duplicate functionality are
different points.
I don't mix anything. The discussion is about binary sizes.
Do I really need to explain why duplicating code/functionality is bad?
No you don't. Do I need to repeat myself about the reasons behind that code?
participants (8)
-
Andrey Semashev -
Antony Polukhin -
Dave Abrahams -
Eric Niebler -
Jeff Flinn -
Klaim - Joël Lamotte -
Tim Blechmann -
Tom Kent