Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 2 Oct 2001 09:41:36 -0700
From: Jon Travis <jtravis@covalent.net>
To: Brian Pane <bpane@pacbell.net>
Cc: dev@apr.apache.org
Subject: Re: apr_vformatter changes & optimizations
Message-ID: <20011002094136.A23519@covalent.net>
References: <20011001134355.A11996@covalent.net>
 <20011001160713.N24906@lyra.org> <20011001202817.A19784@covalent.net>
 <20011001205154.B24906@lyra.org> <3BB9E7FB.1010206@pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3BB9E7FB.1010206@pacbell.net>;
 from bpane@pacbell.net on Tue, Oct 02, 2001 at 09:14:51AM -0700

On Tue, Oct 02, 2001 at 09:14:51AM -0700, Brian Pane wrote:
> Greg Stein wrote:
> 
> >On Mon, Oct 01, 2001 at 08:28:17PM -0700, Jon Travis wrote:
> >
> >>On Mon, Oct 01, 2001 at 04:07:13PM -0700, Greg Stein wrote:
> >>
> [...]
> 
> >>>Personally, I'm guessing that more time is spent assembling than parsing.
> >>>
> >>Since the parsing code is intermingled with the code that throws it into
> >>the final buffer, there isn't a good way of profiling this right now.  
> >>In order to figure out if we are, or not, I'll have to actually write the
> >>code to just-parse or just-output the data, which is the end result of
> >>my question, anyway.
> >>
> >
> >Well, if you want to do the code, who's to stop you? :-)  But I would think
> >it ought to be perf-tested before it goes in.
> >
> 
> In the case of Apache, most of the time spent in *printf is due to calls
> in ap_make_etag() and log_request_time().
> 
> apr_vformatter() represents about 0.25% of the total CPU time in the httpd,
> so it's probably worth optimizing (there aren't many >1% optimizations left,
> except for tables and dir-merge).  But we might get the same improvement
> more easily by optimizing away the *printf calls in ap_make_etag() and
> log_request_time() instead of trying to optimize the formatter itself.

I've written up a preparser and stripped-down vformatter, but the performance
increase is small, and not really worth the split-up code.  It is probably
not even worth it to post the source here.  It does, however, give me the
functionality I need (ability to examine format strings for specific 
info as well as concoct new va_list stylee format lists)

-- Jon