On Sun, 2007-12-16 at 21:57 +0900, Adrian Chadd wrote:
> On Sun, Dec 16, 2007, Tsantilas Christos wrote:
>
> > OK Adrian I fixed this too. You can build the async-calls without
> > enabling of ICAP client.
> >
> > > Next question - if I read this code right, a class is instanced
> for every
> > > async callback being scheduled, is this true?
>
> > Yes this is true. An AsyncCall class instanced for every async
> callback.
>
> And the comm code is going to register one of these per comm events?
> Have you benchmarked what that'll do to performance? :)
>
> Robert's comm code changes in -3 did exactly this, and it trashed
> performance
> at high throughput; hence why I started unwinding it..
I find it hard to buy that root cause analysis has been done here. There
are *lots* of other changes in -3 that will cause memory allocation; and
if allocation is the problem for these async call result classes, then
its likely fixable (for instance, in this specific case, a ring buffer
allocator may be ideal).
There are *python* programs that can saturate gigabit links with a
similar high allocation model.
-Rob
-- GPG key available at: <http://www.robertcollins.net/keys.txt>.
This archive was generated by hypermail pre-2.1.9 : Mon Dec 31 2007 - 12:00:03 MST