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: > > On Mon, Oct 01, 2001 at 01:43:55PM -0700, Jon Travis wrote: > > > I was thinking today that it would be nice to be able to pre-parse > > > *rintf style format strings into an intermediate array. This would > > > have the potential to speed up code which uses *rintf by quite a bit. > > > > Potential vs. demonstrated? > > > > Can you show that we're spendig significant time parsing the format strings? > > Going and throwing a bunch of complexity for a small speedup might not be > > worthwhile :-) > > > > 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. > Another useful feature of being able to pre-parse the list would be to > have the ability to examine the datatypes required for the format. Why > is this terribly useful, you ask? Well, v*printf takes a va_list, which > cannot portably be constructed at run-time. However, if we had a special > apr_va_list, which we could take as an argument to our special formatter > (which also took a preparsed array), we could generate and use v*printf > formats/arguments at runtime. Assume that you create a sentinel-terminated list of non-opaque structures. An app could then programmatically declare that stuff ahead of time and skip the whole parse step. Look at it as a sequence of instructions for assembling bits into a string. Cheers, -g -- Greg Stein, http://www.lyra.org/
