apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Initial profiling data on the SMS pools implementation
Date Sun, 08 Jul 2001 03:13:00 GMT
On Sat, Jul 07, 2001 at 06:25:50PM -0700, Brian Pane wrote:
> Here's my interpretation of the data:
> 1. Ignoring all the configuration-phase stuff, the sms allocation
>    functions are where most of the time is being spent.  (Note:
>    this profile includes only usr time, not sys, and it doesn't
>    include libc.)
> 2. The httpd did about 120 pool allocation operations per request.
>    Apparently there's a lot of code in the httpd that assumes
>    apr_pstrdup is a really cheap function call. :-)
> 3. The original pool implementation spends much of its time in
>    mutex ops, but the SMS-based one doesn't.  This looks like a
>    major win.
> 4. In 500,000 requests, there were 3,088 instances when
>    apr_sms_trivial_malloc called apr_sms_malloc to get more
>    memory from the parent SMS.  (This isn't apparent in the
>    summary below, but it shows up in the detailed gprof output.)
>    This suggests that the initial memory allocation for the
>    per-request pool is typically sufficient to handle all
>    allocations requested from that pool during the request.
> 5. Putting all of these observations together, it looks like
>    much of the SMS allocation cost is contained within
>    apr_sms_trivial_malloc, rather than distributed throughout
>    the framework.  If my conclusion here is correct, that's
>    good news, because it will make optimization a lot easier.

Cool.  Thanks for running this.  =)  BTW, was there a performance
penalty by using SMS?  (I'm knee deep in other stuff right now, so I
don't have time to analyze the performance impact myself.)

I think as we get more experience we'll get even better.  I personally
like that fact that we have decoupled the memory allocation code, so
this now enables us to play with other memory management techniques.
Once it settles down (and I have a solid benchmark program written),
I'll probably play with some different strategies.  Trivial is very
similar to the current pool allocator, so I wonder if there is benefit
by using other allocation strategies.

And, if we arrange the SMS in proper order, threaded MPMs should benefit 
tremendously because we reduce the need for mutex locking (which I think
is far and away where we would see improvement with this code).  Sander 
has a thread SMS (very similar to trivial), but I haven't had a chance 
to look at it yet in detail.  (I don't think he has committed it yet.) 
-- justin

P.S. If you could email me a copy of the gprof output or post it on a
website somewhere, I'd like to take a look at it.

View raw message