Re: [Boost-users] [netlib] throwing exceptions with http_client.cpp

Subject: Re: [Boost-users] [netlib] throwing exceptions with http_client.cpp
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-11-07 00:47:17

On Sun, Nov 7, 2010 at 10:56 AM, Christian Henning <chhenning_at_[hidden]> wrote:
> Hi there,
>
>>
>> It would be good if you tried to put the "http://" part in the source.
>> Try "--source=http://www.boost.org/" or "-S http://www.boost.org/".
>>
>> I just tried it locally and it does require you put a fully qualified
>> HTTP URI -- meaning there should be an 'http://' in the URI.
>>
>
> Thanks, that worked. Cool!
>

Nice, you're welcome. :)

> Can you tell me why the app creates 8 threads? Is there some
> documentation that explains how threads are being used in netlib?
>

That's odd, 8 threads? It only creates 2 AFAIK on Linux, one for the
reactor thread and one for the thread that handles the completion
handlers. Although I do use Boost.Thread shared futures, which may be
creating threads of their own -- I haven't checked yet.

> BTW, I know I raised the pointed before. But compiling my code takes
> up to 1.2GB of memory when compiling boost/network/protocol/http.hpp.

Yeah, happens to me to. Imagine how I get any work done while developing it. :D

> It also takes almost 3min to crunch. Why is that? Are you trying to
> create a compiler benchmark? ;-)
>

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). ;)

HTH

[0] http://goo.gl/3sU8Q

-- 
Dean Michael Berris
deanberris.com