apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Travis <jtra...@covalent.net>
Subject Re: apr_vformatter changes & optimizations
Date Tue, 02 Oct 2001 16:41:36 GMT
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 

View raw message