views:

304

answers:

3

Boost.Asio is great library but it has one huge drawback -- extreamly slow compilation times. A simple implementation (really simple) of HTTP protocol (about 1k lines of code) requires about 13.5s to compile under GCC 4.4!

I tryed to use PCH but it does not improve compilation times too much (about 1s. only).

So are there any tutorials on how to make Boost.Asio compilation times faster?

For example what headers should I exactly include for what class.

I use for example: io_service, tcp::ip::sockets, tcp::ip::acceptor, deadline_timer, buffers and few functions like async_read, async_write.

Any suggestions?

P.S.: I do use pimpl whenever I can.

+2  A: 

What platform? On Linux, both ccache and distcc are awesome, included in most distributions and a snap to set up, either individually or even combined.

Dirk Eddelbuettel
Cross platform, for any compiler. Also I want pure C++ solution.
Artyom
Well, what makes you think there is a speedup gain that the Boost developers left on the table?
Dirk Eddelbuettel
+2  A: 
  • Do you use boost::lambda or boost::bind to construct your completion handlers? boost::bind is less complex => compiles faster.
  • You can profile the compiler with #pragma message() to see if it's the #include-ing or the actual compiling that takes time. I've used this with MSVS to see that sometimes, most of the compilation time is before any code in the .cpp, and other times, it's mostly after. That could help you to profile your compiler's performance. (But, if the preprocessor/#include is fast and run before anything else, it won't give you much)
Marcus Lindblom
I use `boost::bind` and not `boost::lambda`
Artyom
A: 

Well, you probably solved this long ago. But just in case.

Precompiled headers do not magically improve compilation times. They improve cross-translation-unit compile times by cacheing the first header evaluation. Thus you won't see a benefit unless you are #includeing ASIO across multiple source files. Any new template instantiations will further make this last benefit even less noticeable.

I suggest isolating ASIO to a single source file. Don't include ASIO in any 'non-detail' header files. If you must do the latter, try to hide it by using the Pimpl pattern.

If you find yourself requiring ASIO functionality in multiple source files, then think about building an abstraction layer between your code and ASIO. If you keep it as simple as possible, ensuring the bridging code never changes, then you can even #include this interface in the PCH.

dean