httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 20:20:58 GMT

> If you don't copy at all in ap_r*, you're setting yourself up for 
> trouble.  You can't buffer this without copying:
> 
> char buf[100];
> int i;
> int write = 0;
> 
> for(i = 0; i < 100; ++i)
>      {
>      sprintf(buf, "This is line number %d\n", write++);
>      ap_rputs(buf, r);
>      }
> 
> If you're already going to have to copy, why not coalesce at the same 
> time?

We take care of this by using the setaside function.  The reason not to
coalesce, is that we don't know if we want to or not.  Imaging a brigade
that looks like:

immortal(1000 bytes) -> transient(50 bytes) -> heap (200 bytes)

If we coalesce, we end up copying 125 bytes, but only 20 of those need to
be set-aside because they are stack data.

So, carry it through, we copy it all and coalesce, we are left with:

heap (1250)
[copied 1250 bytes]

Now, one of the later filters decides to replace a tag in the middle of
that bucket, so we are left with:

heap(500 bytes) -> immortal (500 bytes) -> heap (500 bytes)

I am assuming we ripped the middle 250 bytes out of the 1250 bytes we
coalesced and replace it with 500 different bytes.  Now, we have to
coalesce again at the bottom.  We have now copied the same data multiple
times, leaving us with:

heap (1500 bytes)
[copied 1500 bytes]

Now, go back to the original brigade, and assume after ap_r* we don't
coalesce, we just set-aside the transient bucket, leaving us with:

immortal (1000 bytes) -> heap (50 bytes) -> heap (200 bytes)
[copied 50 bytes]
The later filter does the 25 byte replacement, and we are left with:

immortal(500 bytes) -> immortal(500 bytes) ->immortal(250 bytes) -> heap(5
bytes) -> heap(200 bytes)
[copied 0 bytes]

Now, we coalesce once at the bottome to:

heap (1500 bytes)
[copied 1500 bytes]

If we coalesce in ap_r*, we copy a total of 1750 bytes, most of which was
actually copied twice.  If we wait until the core_filter, we copy 1550
bytes.  Now, I made those number up off the top of my head.  It would be
easy to show a much bigger savings with slightly different numbers.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message