Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 32212 invoked by uid 500); 3 Oct 2000 19:18:23 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 32198 invoked from network); 3 Oct 2000 19:18:22 -0000 Message-ID: <02ab01c02d6f$8727dbd0$e4421b09@raleigh.ibm.com> From: "Bill Stoddard" To: References: Subject: Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c Date: Tue, 3 Oct 2000 15:24:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > > 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. In summary... -1 on only doing bucket buffering (and not coalescing) in ap_r* +1 on buffering in the chunking filter +0 on coalescing in the core_filter Bill