Stas Bekman wrote:
Currently we allocate a wbucket of type modperl_wbucket_t for each filter invocation. If it's not a streaming filter (i.e. manipulates bucket brigades or doesn't use read/print) it's never going to need wbucket. wbucket consumes 16404 bytes, the filter struct without wbucket consumes 60 bytes. In order not to penalize non-streaming filters, I suggest not to allocate wbucket if and not until it's first used.
I'm getting too comphy with pools and this patch of course forgets to free memory, now that it has moved to malloc.
you're still way ahead of the game here, so go with what you think is best (thanks for asking, though :)
Are you talking about premature optimization, or are you just implying that you hadn't caught up with filters implementation yet?
if you have the time and can explain what a wbucket is, that would be great, too :)
modperl_wbucket_t is a struct that mod_perl uses to pass data to from response handler to the first filter, or from any mod_perl filter to the next filter. e.g. it's used every time ($r|$f)->(print()|flush()) and some other variants are called.
It includes a buffer of fixed size and a few other records. It's very efficient in the response handlers, since it's allocated only once for each request.
Only filters that use streaming API and call $f->print() need this buffer.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
