Hi! I have looked around in the documentation and FAQs about my question, but I don't seem to have found a satisfying answer. My problem is that the boost libraries (especially function) seem to successfully boost the code size of my C++ Builder program, too. The source written by me is around twenty-some thousands of lines, plus the VCL and stdc++ headres, the end result may be somewhere around half a million lines in summary. But after having added some boost headers (mainly function and bind) to where it's appropriate, the amount of compiled lines on a full rebuild jumped to the ten million (!) range. This is way too much. I'm not using any so that much advanced stuff that it would be justified - and the compilation time is inacceptable for such a small app. So, does anyone have some clues regarding why boost may cause so much bloat, and how I could reduce that? thx mortee
Marton Fabo wrote:
This is way too much. I'm not using any so that much advanced stuff that it would be justified - and the compilation time is inacceptable for such a small app.
Just out of curiosity, why is compilation time a big deal? I understand being concerned about the size of the final executable, but how often are you compiling? (and if it's that often, why?).
This is way too much. I'm not using any so that much advanced stuff that it would be justified - and the compilation time is inacceptable for such a small app.
Just out of curiosity, why is compilation time a big deal? I understand being concerned about the size of the final executable, but how often are you compiling? (and if it's that often, why?).
Sometimes. It's a maturing program with maturing specifications. I, of course, need to make a lot of modifications, and test their effect, not just code blindly. So I have to compile often. And, just to add to the problem, because of the ever changing expectations, there are a lot of header modifications, which naturally cause recompilation of all the affected units - even slower test cycle. I'm not sure about that the progress bottleneck really should be code bloat caused by a library - or that it should force me to perform a different programming cycle style. Additionally, that (less frequent compiling and testing) wouldn't fix, just work around the problem at hand. mortee PS: to prevent that argument early: I don't really need advices telling me to stop using boost if it causes problems - I can deduce that if/when necessary too...
Marton Fabo
This is way too much. I'm not using any so that much advanced stuff that it would be justified - and the compilation time is inacceptable for such a small app.
Just out of curiosity, why is compilation time a big deal? I understand being concerned about the size of the final executable, but how often are you compiling? (and if it's that often, why?).
Sometimes. It's a maturing program with maturing specifications. I, of course, need to make a lot of modifications, and test their effect, not just code blindly. So I have to compile often.
And, just to add to the problem, because of the ever changing expectations, there are a lot of header modifications, which naturally cause recompilation of all the affected units - even slower test cycle.
I'm not sure about that the progress bottleneck really should be code bloat caused by a library - or that it should force me to perform a different programming cycle style. Additionally, that (less frequent compiling and testing) wouldn't fix, just work around the problem at hand.
As we move more and more smarts into compile-time code (template
metaprogramming), compilation times naturally go up, especially since
C++ templates weren't really designed for the sorts of things we're
asking of them. The possibility of Template Metaprogramming is sort
of a lucky accident. You can cut the compilation time a bit by using
only the "portable" syntax and #including only
You can cut the compilation time a bit by using only the "portable" syntax and #including only
for the appropriate Ns. That will expose less code to the compiler, though I wouldn't expect a dramatic change.
I will try that, thanks.
The interesting thing about your problem is that Boost.Function is exactly the sort of thing one uses to *eliminate* recompilation dependencies: by hiding the real type of the member/function pointer or function object it wraps behind a single polymorphic type, you can prevent changes to the wrapped type from affecting other code.
Well, yes. Ideally, it would do that, but unfortunately the concepts I want to implement in the program in question aren't yet mature enough either - and every change to a class definition which uses function.hpp will cause the other compilation units which use that class to be recompiled, along with function.hpp ...
One thing to keep in mind: Boost.Function can be expensive to copy (both in time and in code space) if you're wrapping stateful function objects. Consider passing it by reference.
OK, I'll keep that in mind. thx mortee
Marton Fabo
This is way too much. I'm not using any so that much advanced stuff that it would be justified - and the compilation time is inacceptable for such a small app.
Just out of curiosity, why is compilation time a big deal? I understand being concerned about the size of the final executable, but how often are you compiling? (and if it's that often, why?).
Sometimes. It's a maturing program with maturing specifications. I, of course, need to make a lot of modifications, and test their effect, not just code blindly. So I have to compile often.
And, just to add to the problem, because of the ever changing expectations, there are a lot of header modifications, which naturally cause recompilation of all the affected units - even slower test cycle.
I'm not sure about that the progress bottleneck really should be code bloat caused by a library - or that it should force me to perform a different programming cycle style. Additionally, that (less frequent compiling and testing) wouldn't fix, just work around the problem at hand.
As we move more and more smarts into compile-time code (template
metaprogramming), compilation times naturally go up, especially since
C++ templates weren't really designed for the sorts of things we're
asking of them. The possibility of Template Metaprogramming is sort
of a lucky accident. You can cut the compilation time a bit by using
only the "portable" syntax and #including only
Marton Fabo
This is way too much. I'm not using any so that much advanced stuff that it would be justified - and the compilation time is inacceptable for such a small app.
Just out of curiosity, why is compilation time a big deal? I understand being concerned about the size of the final executable, but how often are you compiling? (and if it's that often, why?).
Sometimes. It's a maturing program with maturing specifications. I, of course, need to make a lot of modifications, and test their effect, not just code blindly. So I have to compile often.
And, just to add to the problem, because of the ever changing expectations, there are a lot of header modifications, which naturally cause recompilation of all the affected units - even slower test cycle.
I'm not sure about that the progress bottleneck really should be code bloat caused by a library - or that it should force me to perform a different programming cycle style. Additionally, that (less frequent compiling and testing) wouldn't fix, just work around the problem at hand.
As we move more and more smarts into compile-time code (template
metaprogramming), compilation times naturally go up, especially since
C++ templates weren't really designed for the sorts of things we're
asking of them. The possibility of Template Metaprogramming is sort
of a lucky accident. You can cut the compilation time a bit by using
only the "portable" syntax and #including only
Marton Fabo
But after having added some boost headers (mainly function and bind) to where it's appropriate, the amount of compiled lines on a full rebuild jumped to the ten million (!) range.
Have you tried including the boost headers in your precompiled header? Also see http://www.bcbdev.com/articles/pch.htm for optimising the use of precompiled headers. Hugo
On Monday 20 October 2003 09:11 am, Marton Fabo wrote:
But after having added some boost headers (mainly function and bind) to where it's appropriate, the amount of compiled lines on a full rebuild jumped to the ten million (!) range.
This can be a real pain. One way to shrink Boost.Function down a bit (though
probably not enough) is to use the argument-number---specific headers, e.g.,
#include
participants (5)
-
David Abrahams -
Douglas Gregor -
Hugo Duncan -
Mark Sizer -
Marton Fabo