> On Thu, Jun 28, 2001 at 08:28:41AM -0700, Ian Holsman wrote: > > I'm in the middle of writing a pool-tester > > which can take a file and pool allocation commands > > (alloc/create/destroy/etc) > > and replay them. > > combine this with some threads, and a capture tool in the current pool > > code and we should be able to test different pooling algorithms easily. > > > > (should be done today) > > Yea, please post when you are done! My gut feeling is that threaded APR > is just awful at pool allocation right now. =) If we use SMS, it'd be > nice to have some way of knowing whether we are faster than what we > have now. Baselines (no matter how sucky) are good to have before > embarking on such a change. I wonder how the SMS stuff will mix with a > prefork MPM - which never needed locking in the first place. Be worth > checking out. -- justin
We are currently working on a way to do 'locking on demand'. Possibly I have some more time next week to work on that. In a single thread, performance between a pool like sms and pools is almost the same. It varies between +5% and -5% *). However, with a variety of choice between smss you should be able to choose a 'best performing' sms for a certain situation (ie. if you know you only are going to allocate blocks of the same size, use sms_blocks). Sander *) On my machine (linux 2.4.3, glibc 2.2.2, gcc 2.95.2.1), using test/testmem.
