apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: cvs commit: apr-util CHANGES
Date Mon, 23 Sep 2002 02:00:42 GMT
On Sun, 2002-09-22 at 16:34, Greg Stein wrote:

> Ewww... icky implementation... If you have a dozen iovec's where each
> iov_len is slightly less than APR_BUCKET_BUFF_SIZE, then you're going to
> copy the entire thing onto the heap.
> 
> >   +    /* Step 3: if necessary, output the brigade contents now
> >   +     */
> >   +    if (bytes_written >= APR_BUCKET_BUFF_SIZE) {
> >   +        return flush(b, ctx);
> >   +    }
> 
> And *then* you're going to flush the thing.

That part definitely is a problem.  The apr_brigade_writev() code
needs to flush the brigade each time it overflows the previous
heap buffer.  I'll add a fix for that.

All the copying doesn't bother me as much, because it's the same
thing that would happen if you did a dozen calls to apr_brigade_write()
for slightly less than APR_BUCKET_BUFF_SIZE bytes each.  So the copying
overhead in this case would be no worse than apr_brigade_write().

> If you total up the number of bytes represented by the iovec, and that total
> is more than APR_BUCKET_BUFF_SIZE, then simply create <nvec> TRANSIENT
> buckets and flush the thing. No copies at all.

That approach would create some different problems, though.  Consider
a case where the vector consists of a few dozen small strings followed
by a large buffer--for example, a lot of small bits of text comprising
a response header, followed by a >8KB buffer containing the response
body.  If we create two dozen transient buckets, we could end up doing
extra copying: a copy per bucket if any filter tries to setaside the
brigade, plus a copy in the core_output filter as it tries to combine
the many tiny buckets into one larger buffer.

Brian




Mime
View raw message