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>.
signature.asc
Description: This is a digitally signed message part
