Boost and C++ "physical design"

[yangzhang]

I have a couple questions about Boost and its implications for the
"physical design" of C++ projects.

I'm guessing there probably aren't that many non-member, non-template
functions in the Boost library, but of the ones that exist, are these
usually labeled `static`, since boost is mostly a header library?

Is there any advice on taming (1) the generated code size and/or (2) the
build times* which result from using a header-mostly library like Boost?
  A large C++ project consists of many translation units (.o files)
which are generated from source files that include many of the same
Boost headers over and over again.  (2) can be ameliorated with a
distributed build process, but the more general issue here is that of
consumption of compute resources, be it time or machines.
--
Yang Zhang
http://www.mit.edu/~y_z/
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[SubWoofer]

On Fri, 20 Mar 2009 10:20:21 +0100, Yang Zhang <yanghatespam@...>
wrote:

> Is there any advice on taming (1) the generated code size and/or (2) the
> build times* which result from using a header-mostly library like Boost?
>   A large C++ project consists of many translation units (.o files)
> which are generated from source files that include many of the same
> Boost headers over and over again.  (2) can be ameliorated with a
> distributed build process, but the more general issue here is that of
> consumption of compute resources, be it time or machines.

I can't say much about (1), but for (2) I can share some experience. Most
of the compile time comes from recompiling the same headers over and over
again, so reducing the number of header files parsed for each translation
unit pays dividends.

We use forward declarations in header files extensively, and only include
header files in header files where ABSOLUTELY necessary. This sometimes
means that we use pointers and shared_ptr<>s for holding stuff that is
strictly speaking an accumulated class member, depending how much code
includes the class in question. A forward declared "pimpl" can also help a
lot.

HTH!

--
Joachim Pihl
Senior R&D Engineer
Nevion

Tel: [phone]
Fax: [phone]
Mobile: [phone]
jpihl@...
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Václav Haisman]

Yang Zhang wrote, On 20.3.2009 10:20:
> I have a couple questions about Boost and its implications for the
> "physical design" of C++ projects.
>
> I'm guessing there probably aren't that many non-member, non-template
> functions in the Boost library, but of the ones that exist, are these
> usually labeled `static`, since boost is mostly a header library?
I think they are mostly marked inline rather than static.

>
> Is there any advice on taming (1) the generated code size and/or (2) the
What do you want to tame here? Sizes of executables are IME not a problem,
unless you are on severally constrained embedded platform. Few megabytes of
executable are usually insignificant compared to huge data sets that acompany
it.

> build times* which result from using a header-mostly library like Boost?
>  A large C++ project consists of many translation units (.o files) which
> are generated from source files that include many of the same Boost
> headers over and over again.  (2) can be ameliorated with a distributed
> build process, but the more general issue here is that of consumption of
> compute resources, be it time or machines.
Any decent compiler supports precompiled headers. Those help quite
significantly with compilation time of source that uses Boost, IME.

--
VH
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Christopher Currie]

2009/3/20 Václav Haisman <v.haisman@...>:
> Yang Zhang wrote, On 20.3.2009 10:20:
>> Is there any advice on taming (1) the generated code size and/or (2) the
> What do you want to tame here? Sizes of executables are IME not a problem,
> unless you are on severally constrained embedded platform. Few megabytes of
> executable are usually insignificant compared to huge data sets that acompany
> it.

This is a naïve view at best. Commercial software, especially
downloadable software, can be very sensitive to application size both
due to the perception of bloat as well as the desire to improve
adoption by reducing the barrier of entry. This counts both for adding
new pre-compiled DLLs as well as the additional code size from
template instantiation.

I think that most Boost library maintainers are sensitive to the issue
of code size, and that the libraries that implement non-member
non-template function do so in a compiled library *because* they wish
to control code bloat. If there examples you see in the code where
this is not the case, there may be someone on the list who could give
an engineering rationale for why that is.

HTH,
Christopher
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[yangzhang]

Václav Haisman wrote:
> Any decent compiler supports precompiled headers. Those help quite
> significantly with compilation time of source that uses Boost, IME.

I (and others) have found that precompiled headers don't actually help
that much with build time.  It only saves on parsing and name lookup
time, not on code generation time.
--
Yang Zhang
http://www.mit.edu/~y_z/
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Raindog]

Yang Zhang wrote:
> Václav Haisman wrote:
>> Any decent compiler supports precompiled headers. Those help quite
>> significantly with compilation time of source that uses Boost, IME.
>
> I (and others) have found that precompiled headers don't actually help
> that much with build time.  It only saves on parsing and name lookup
> time, not on code generation time.
In my experience, code generation time is minuscule compared to the rest
of the process, especially with libraries like spirit and xpressive.

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Emil Dotchevski-3]

On Sat, Mar 21, 2009 at 11:05 AM, Raindog <raindog@...> wrote:

> Yang Zhang wrote:
>>
>> Václav Haisman wrote:
>>>
>>> Any decent compiler supports precompiled headers. Those help quite
>>> significantly with compilation time of source that uses Boost, IME.
>>
>> I (and others) have found that precompiled headers don't actually help
>> that much with build time.  It only saves on parsing and name lookup time,
>> not on code generation time.
>
> In my experience, code generation time is minuscule compared to the rest of
> the process, especially with libraries like spirit and xpressive.

Whether or not precompiled headers lead to faster builds is besides
the point, because they increase coupling.

The point of good physical design is to reduce coupling. Reduced
coupling has many benefits beyond its effect on build times, in fact
it often leads to slower "full rebuilds". Also, good physical design
sometimes requires compromises with logical design, type safety, or
even performance.

The problem is that bad physical design has no measurable effects on
anything until it's too late. Once it becomes a problem, reducing
physical coupling is very difficult. Boost with its header only nature
is beyond that point, IMO.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Vladimir Prus-3]

Christopher Currie wrote:

> 2009/3/20 Václav Haisman <v.haisman@...>:
>> Yang Zhang wrote, On 20.3.2009 10:20:
>>> Is there any advice on taming (1) the generated code size and/or (2) the
>> What do you want to tame here? Sizes of executables are IME not a problem,
>> unless you are on severally constrained embedded platform. Few megabytes of
>> executable are usually insignificant compared to huge data sets that acompany
>> it.
>
> This is a naïve view at best. Commercial software, especially
> downloadable software, can be very sensitive to application size both
> due to the perception of bloat as well as the desire to improve
> adoption by reducing the barrier of entry. This counts both for adding
> new pre-compiled DLLs as well as the additional code size from
> template instantiation.

I completely agree. Program size might not be a practical factor when a program
is already installed on a desktop computer with 500G hard drive. But somebody
sitting in a cafe and downloading the same program over free wifi onto his netbook
will surely appreciate reasonable size.

> I think that most Boost library maintainers are sensitive to the issue
> of code size, and that the libraries that implement non-member
> non-template function do so in a compiled library *because* they wish
> to control code bloat. If there examples you see in the code where
> this is not the case, there may be someone on the list who could give
> an engineering rationale for why that is.

I'd like to be wrong, but I think I saw the issue of code size dismissed,
and I am not aware of any systematic approach to measure code size impact
of individual libraries. Few years ago I've did some measurement for program_options
-- it terms of 'bytes of code to declare one option'. This proved
fairly entertaining, but clearly, measuring code size impact of one operation
may easily miss other sources of code bloat.

- Volodya


_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users