Sure, check that sucker in! david > > Well, just running it here's what I get... > > > > For 50 loops malloc()/free() took 3183232 > > malloc() took 3009073 > > free() took 174159 > > For 50 loops pool_get()/pool_put() took 1400692 (44%) > > pool_get() took 902635 (29%) > > pool_put() took 498057 (285%) > > > > These look good for me! > > Is this the old pool code, or the new one? > > Anyway, I have put some #ifdef in the code to use benaphores instead of > a read/write lock (if POOL_USES_BENAPHORES is 1 at compile time): > > With a block size of 256 bytes: > > For 50 loops malloc()/free() took 125041 > malloc() took 108324 > free() took 16717 > For 50 loops pool_get()/pool_put() took 12664 (10%) > pool_get() took 6626 (6%) > pool_put() took 6038 (36%) > > Should I check this code in? Of course it's much faster for this test, > but it may be slower when there is much concurrent access. > And we could go back to a read/write lock when we set > POOL_USES_BENAPHORES to 0 in no time (could be nice to check that once > the whole stack is done). > > > Guess which one is our stack and which is BONE? Not what I would have > > expected at all really... > > Nice :-) > > Adios... > Axel. > > > >