Peter Dimov wrote:
Rene Rivera wrote: [...] Two things come to mind...
1. What inefficiencies are inherent to the design, and what are simply an implementation detail, and
Good question, and I'm not sure I can currently discern in this case which part is a design problem or implementation problem as both seem to be intertwined. From what I understand the design would allow for writing a custom demuxer/demuxer_service that optimized the dispatching. But doing that would prevent the reuse of the various implementation services (epoll, iocp, kqueue, select) as they are an internal detail to the default demuxer_service. So I think it's a design problem that this particular core functionality can't be reused, or customized, to perform differently.
2.
Did you try to use the library?
No.
It'd probably be helpful if you create a simple throughput test and post the results so that there is a clear target for Asio to match or exceed. This will also validate your objections as they currently seem to be based on intuition. :-)
Working on it... But it's not an intuition based objection, but an experiential objection. In my experience memory allocations are the biggest bottleneck in algorithms as they insert, at best, logN steps inside of inner loops. -- -- 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