Re: [boost] [review] Asio formal review.

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-12-21 11:48:39

Christopher Kohlhoff wrote:
> Hi Rene,
> 
> In my first reply to your review I outlined a proposal for
> custom memory allocation. I have now implemented enough of it to
> re-run your test program (updated program and results attached).

OK.

> --- Rene Rivera <grafik.list_at_[hidden]> wrote:
> 
>>I ran the same 100,000*1K*6*2*3 tests with both debug and
>>release compiled code. As can be seen from the attached output
>>in the best case, of release code, there is a 5.6% "overhead"
>>from the async to sync cases.
> 
> Machine specs: 1.7GHz Pentium M, 512MB RAM, Windows XP SP2.
> Compiler: VC8 Express.
> 
> First, without custom memory allocation a typical run of the
> program made approximately 340000 calls to new. With my custom
> memory allocation there were just 80.

Much better :-)

> In the release build async calls were marginally slower, but the
> difference was less than 1%.
> 
>>For the debug code the difference is a more dramatic 25.2%.
> 
> Even though a debug build is not really relevant for performance

Of course... I was being as complete as possible.

>>In my continue reading and use of the code I concluded that
>>the basic design flaw is that the underlying *socket_service
>>classes are not available as a public interface.
> 
> I don't understand how not exposing the implementation details
> is a design flaw.

You might consider it an implementation detail. But depending on the
context it might not be considered a detail. At minimum, in this case, I
would expect to be able to choose which implementation to use. And in
some situations I might want to make that choice at runtime, not just
compile time. For example some would consider the std::deque<T>
container behind an std::stack<T> to be an implementation detail. But I
might want to use a circular_deque<T> instead, for those cases where I
want to make certain memory guarantees. After all it's how we draw the
abstraction line that we worry so much about in Boost. In this case I
think you've drawn the line too far up preventing some alternate uses of
your library.

>>Another restriction that this causes is that the various OS
>>handling models are not available as individual handling
>>types. Hence, for example on Linux, it is not possible to
>>choose at runtime whether one should use epoll, kqueue, or
>>select.
> 
> The stated intention is to use the most scalable event
> demultiplexer offered by a platform.

Sure, but scalability is a contextual measure. In my use case the
scalability is not measured in how many connections are handled at once
since my connections are all virtual and is only limited by bandwidth
and protocol limits.

> Furthermore, runtime
> polymorphism is likely to limit the opportunity for
> optimisation. E.g. the custom allocation strategy I have
> implemented works because the user handler types have not been
> erased.

I didn't realize I implied runtime polymorphism. I was only thinking of
the simple ability to create different kinds of clients/servers based
the OS signaling method. It's not possible right now since one can't
instantiate in a type safe manner different datagram_socket_service
variants. for example.

> I'd be interested to know whether you, or others, find this
> custom memory allocation interface satisfactory.

It's OK. It solves the allocation problem, but not the reuse problems.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org