apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: Bucket memory allocation (was Re: SMS parm to bucket_foo_create())
Date Mon, 27 Aug 2001 13:49:29 GMT
On Sun, 26 Aug 2001, Greg Stein wrote:

> Thread-specific globals are just that: globals. Passing as a parameter gives
> you clarity/maintainability/flexibility/etc. And it can also mean some real
> performance gains in certain places.

That is definitely in-sync with the conclusion that was reached in
previous debates on this matter.  Ignoring the obvious flexibility and so
on and just talking about pure performance, it boiled down to this
example: If you force the buckets code itself to do a little extra work
each time you create a bucket to (look up the SMS|find its free
list|insert your own semantic), then what's going to happen to filters
that create a buttload of buckets?  They're going to have to do tons and
tons of redundant work.  It'd be nice if you only had to do that work once
and propagate the result to the later buckets.  But if you're giving the
caller the interface to do that, the caller might as well figure out what
SMS it wants wayyyyy ahead of time and stash it somewhere so that you
REALLY avoid doing redundant work.  All you have to do per-bucket is take
a pointer from somewhere (eg the conn_rec) and pass it in.  That's clearly
a performance gain over any system that involves per-bucket-creation work.

> Also note that you may want different SMSs based on *applicability* rather
> than based on thread. One SMS for FILE buckets, one SMS for pool buckets,
> etc. And that determination will be made at create time, rather than through
> a "what thread am I on?" question.

That is another benefit, sure.  Though while we're definitely not limited
to a single SMS for all bucket types, what I think we're going to see is
that the best SMS for buckets in general is one that can hand out little
blobs of about 20-60 bytes at a time really really really fast (that's the
approximate range of sizes for various bucket structures) and recycle them
very efficiently.  That's why David and Sander wrote the blocks SMS in the
first place--they had this specifically in mind.  The SMS would not used
to allocate any of the APR structures like apr_file_t, of course, nor
would it be used to allocate space for _data_.  (Unless somebody makes up
an SMS bucket type as a complement to heap and pool buckets, which I'm all
for.  It would probably look a lot like the pool buckets except that it
could fall back on an sms_std instead of having to morph itself to a heap
bucket if the SMS got cleaned up.)

> On a separate note, I really didn't like that last checkin for the buckets
> at all. If you're going to introduce a temporary global variable, and some
> temporary logic in every create function, then I'd suggest two things when
> you do so:
> 1) comments on the globals to that effect
> 2) the per-create logic could be encapsulated in a single macro to minimize
>    the line-count changes in those functions, and to focus users on a macro
>    which is commented as being transitory.

That's a good point.  There was a tiny comment in there on the variable
declaration in the header, but I was counting on the commit message to
make it clear that the rest was temporary as well.  More comments and a
macro would have been a good idea.  I'll keep that in mind if I ever have
a need for something like this again.


   Cliff Woolley
   Charlottesville, VA

View raw message