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
