Hi Dean,
Well, to explain a few reasons why, I'd have to point you to the paper I wrote for BoostCon 2010 which I also gave a talk about. [0] In a nutshell:
1. I use Boost.Spirit internally for parsing -- that already exercises the compiler alone.
2. The tag dispatch mechanism used to determine the behavior of the implementation at compile time relies on template metaprogramming. Traits, factories, and selections are done using tag dispatch which relies heavily on Boost.MPL.
3. The amount of code that's already in the library lends itself to using a lot of memory, and especially since everything is a template, that's more time the compiler spends in processing the templates.
The code generated then is as efficient as the compiler can make it -- I hide nothing from the optimizer, and all the opportunities for optimization are there. Functions are inlined, loops unrolled, and in some cases operations are vectorized by the compiler's optimizer.
I'm trying (hard) to get the compile times down but adding new features to the HTTP server part and later on supporting more overloads to member and free (template) functions will only make the compile time pretty heavy (or heavier, depending on how you look at it). ;)
Thanks for your insight. It's very interesting! I'm sure this idea already came up but why not let the user have the option of making parts of netlib compile into a lib? Thanks, Christian