[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    Re: sms_trivial locking  Re: missing apr_pool_child_cleanup_set when using SMS?
From:       "William A. Rowe, Jr." <wrowe () rowe-clan ! net>
Date:       2001-07-27 16:08:42
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]