On Sun, 2002-06-30 at 20:57, Justin Erenkrantz wrote: > On Fri, Jun 28, 2002 at 07:01:34PM -0700, Ryan Bloom wrote: > > Have you looked at which of these are causing the most performance > > problems? It seems to me that the easiest thing to do, would be to use > > a persistent brigade, which removes two steps from this. > > I'd really prefer that we decouple this persistent brigade from the > request_rec. We used to have it coupled (req_cfg->bb) and it made > the code too confusing as other places started to rely on this > brigade. So, I'd like to not go back down that road and figure out > a better scope for such a persistent brigade (a filter context seems > about right for the scope).
The brigade can't be in a filter context, because then it wouldn't be accessible from ap_rgetline_core(). The request_rec is the only place where we could easily put this brigade. We just need to name it something like "temp_working_brigade" and document the fact that any function that puts things in that brigade must clear them out before it exits. > Yet, my real desire here is to figure out how to make brigade creation > and destruction faster. I think the problem is that pool cleanup > registration and destruction is *very* slow. So, perhaps, that'd > be the place to focus on if we're concerned that brigades are just > too expensive. If we're going to go to all of this hassle to avoid > creating brigades (which IMHO should be cheap to create and destroy), > then that means we should speed this up instead of avoiding this real > problem. I don't see why a brigade should be a heavyweight object - > they seem like they should be extremely lightweight. The pool cleanup registration and cancel operations aren't particularly inefficient (though I think there's some room for optimization). The problem is the large number of calls to these operations per request, due to the multiple brigade creations/deletions per header line. --Brian
