apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: sms_trivial locking Re: missing apr_pool_child_cleanup_set when using SMS?
Date Fri, 27 Jul 2001 16:08:42 GMT
From: "Brian Pane" <bpane@pacbell.net>
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


Mime
View raw message