httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Wed, 04 Oct 2000 13:33:23 GMT


> On Tue, 3 Oct 2000, Bill Stoddard wrote:
>
> > >
> > > ap_r*.  These are older functions.  They are likely to always work,
> > > because they are very useful.  Currently, they have horrendous
> > > performance.  The way to solve this, is to allow ap_r* to buffer data.  If
> > > multiple calls to ap_r* are made, the buckets should be buffered until it
> > > is worth it to send the data.
> >
> > I just reread this and I completely disagree. ap_r* needs to coalesce data
in
> > addition to buffering buckets. ap_r* routines can never be sure of the scope
of
> > the storage passed to them, so you will need to setaside all the calls. It
makes
> > more sense to just explicitly alloc an output buffer inside ap_r* and copy
bytes
> > into that buffer. When you meet your threshold conditions, turn that buffer
into
> > a bucket of suitable type and send it down the chain.
>
> So, in other words, if a handler allocates small chunks of data and uses
> ap_r* to write it, we will copy once in the handler, once in ap_r* and
> potentially once more in core_fitler.

Ummm, no. If bytes are coalesced in ap_r*, in most cases (and maybe all cases)
the trigger to cause core_filter to coalesce will not be hit. Byte moves will
not generally happen lower in the chain. The advantage of coalescing near the
source is that the resulting data patterns are more cache friendly because you
have a shot at keeping most everything in a cache page. Furthermore, there is a
lot of overhead associated with handling brigades with 1000's of buckets. Taking
your approach, ap_r* can 'buffer' several thousand buckets, each allocated from
different parts of the heap. Each bucket in turn references bytes allocated from
who knows where. Then we send this big brigade down the chain. Each filter has
to do multiple (10's of thousands of) pointer indirections just to traverse each
bucket and 'filter' a few bytes of payload.  And because all the referenced data
is scattered all across the heap, you will not be using your cache efficiently.

Bill


Mime
View raw message