apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: apr_vformatter changes & optimizations
Date Tue, 02 Oct 2001 16:14:51 GMT
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.

--Brian




Mime
View raw message