httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@covalent.net>
Subject Re: ap_r* performance patch
Date Mon, 22 Jan 2001 23:35:58 GMT
On Mon, 22 Jan 2001 rbb@covalent.net wrote:
 
> Yeah, but you were strictly testing a handler.  Try doing that with a
> filter and Greg's patch.  The filter is registered as an
> FTYPE_CONTENT + 1, so it MUST be at the very top of the filter stack, it
> is not possible to insert it after a mod_perl filter.

so this means i'd still have to use the modperl buffer thingy.
and i would have to use it for connection-level filters (where there is no
r or r->output_filters).  but with rbb.patch i can use apr_brigade_*
anywhere.  ap_r* improvements are not useful to me if i can't throw away
the current modperl buffer api.

seems to me that: 
- rbb's design is more flexable/usable
- both are very close performance wise
- rbb's might require a call to ap_sync_output() or apr_brigade_flush()

if i'm following correctly, the last is greg's major argument against
rbb's, is this still true?  personally, i don't see the big deal with
having to call a flush or sync function.  yeah, it might end up biting
somebody, but that's not enough imho to sacrifice flexabilty.

the more i think about it, the more i really like apr_brigade_*
being usable outside of the request_rec and outside of httpd.  libapr is
rad, i've used it to write 3 libraries so far that work outside of httpd,
an http/s client, rewrite of cybersource's client library and a generic
credit card clearing house api.  filtering in the http/s client would be
useful and i could use apr_brigade_* instead of BIO_* in the cybersource
client.


Mime
View raw message