Return-Path: Mailing-List: contact modperl-help@apache.org; run by ezmlm Delivered-To: mailing list modperl@apache.org Received: (qmail 33402 invoked from network); 1 Mar 2000 07:42:28 -0000 Received: from adsl-216-103-208-11.dsl.snfc21.pacbell.net (HELO mojo.itixs.com) (216.103.208.11) by locus.apache.org with SMTP; 1 Mar 2000 07:42:28 -0000 Received: from localhost (dougm@localhost) by mojo.itixs.com (8.8.8/8.8.8) with ESMTP id XAA23863; Tue, 29 Feb 2000 23:38:38 -0800 X-Authentication-Warning: mojo.itixs.com: dougm owned process doing -bs Date: Tue, 29 Feb 2000 23:38:38 -0800 (PST) From: Doug MacEachern X-Sender: dougm@mojo.itixs.com To: Jim Winstead cc: modperl@apache.org, dougm@apache.org Subject: Re: libapreq's multipart_buffer stuff In-Reply-To: <20000224021802.A8369@trainedmonkey.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Thu, 24 Feb 2000, Jim Winstead wrote: > Is it just me, or is it pretty dodgy code? It allocates memory like > its going out of style (it doesn't appear to reuse any of the > buffers it allocates from the pool), resulting in server processes > that balloon up to five times the uploaded file's size. Its also > appears to be flat-out slow because of all the extra work it is > doing. it's pretty dodgy code :) the multipart buffer code in libapreq is actually just a translation from CGI.pm's Perl code to C. notice the comment: /*XXX: we can optimize this loop*/ meaning, I'm aware it's not reusing the buffer, but it's using a subpool which is cleared at the end of multipart_buffer_fill, each call to that should be no more than 4k or so. I have a recent mail (not to the list) from somebody who experienced the balloon, looked into it, and thinks that ap_clear_pool() is not working. anyhow, my plan is to get 1.22 out, then revisit libapreq, then onto modperl-2.0