From: "Brian Pane" <[EMAIL PROTECTED]> Sent: Friday, July 27, 2001 2:05 AM
> Justin Erenkrantz wrote: > > >Right now, I've got it so that most of the locks are now in libc > >(aka NIMBY), but the performance still doesn't match pools (by a > >factor of 2). I'm scratching my head as to why this is. > > > hmmm...looking at the code, it makes sense that SMS is > half as fast as the original pools code. I didn't realize > this until just now, but the polymorphism in the SMS framework > will probably make it impossible to match the performance of pools: > > * apr_palloc (the original pools version) is a very lightweight > function in the fast-path case where it doesn't need to > acquire a lock. It consists of a couple of integer/pointer > arithmetic operations and two comparisons. > > * The SMS-based implementation has to do essentially the same > work, but it also does an extra function call (apr_sms_malloc > calls apr_sms_trivial_malloc). > > * If the cost of a function call is similar to the cost of > the two comparisons and half-dozen arithmetic operations > in apr_palloc, that would explain why the SMS version is > twice as slow. You just answered your own question. Instead of conditionals and stepping around the locking code, it should be the thread attach/detach that decides (when it decrements to 1 or increments above 1 thread) to flip the fn pointers in the SMS to the lock-safe or lock-free functions. Since the indirection is _already_ one pain point, make it a productive one :) Bill
