coolfluid/coolfluid3 — Issue #146: Compilation too slow
Author: wdeconinck
Created: 2011-10-30 22:50:51+00:00
State: open
Labels: BUILD, IDEA

Looking at the compilation time of CF is really dissapointing.

We all know that boost and stl headers are the main culprit.

Component.hpp should be a very lean header.

I looked at the Component.hpp class and saw that the boost::iterator_facade is included (big header)

This include could be completely avoided by putting "ComponentIterator" in another file, but on one condition: the templated versions of
`begin()` , `recursive_begin()`, `end()`, `recursive_end()` be removed.

It makes a bit of sense to remove this here, because this is already a filtering-operation, which can as well be done in the "FindComponents" function, `find_components_recursively`.
This is what everybody uses in practice.

On the same note, we should really NOT include Eigen/StdVector in CF.hpp
The include on this file is horrible. It basically covers Eigen entirely.
My test shows this include takes an extra 32 seconds to compile coolfluid_common, corresponding to about 0.5 second per file, and coolfluid has a LOT of files ;)
We should maybe think of removing the `` and `` include from CF.hpp as well, and then be careful to use Eigen's `std::vector` or the real `std::vector`.

----

Note also that many headers of boost have `xxx_fwd.hpp` versions (such as `boost/function/function_fwd.hpp`)
These type of headers should be used as much as possible in our header files.

I have already played with it a little bit, and been able to snoop time off of coolfluid_common compilation (which doesn't even have that many components)
This mainly by forward declaring `boost/function/function_fwd` in `Option.hpp` and
moving the boost includes from `AllocatedComponent` inside the `#ifdef CF3_ENABLE_COMPONENT_TIMING` guard, obviously with the timing capability disabled.

After this tinkering, the only boost headers remaining in Component.hpp is now boost/iterator_facade.hpp and boost/any.hpp.
The latter is impossible to remove, but iterator_facade could be removed under above mentioned conditions.

---

By the way, I discovered there is a forward declare for `` called ``
We always avoided including `` (or ``) as it is a HUGE header.
But this ``allows us to create streaming `operator<<()`and `operator>>()` without sacrificing compilation!
I implemented this for URI, on my local repo. No need to type `std::cout << uri.string();` but just `std::cout << uri;` NICE
Will commit this later.