Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 1 Oct 2001 20:51:54 -0700
From: Greg Stein <gstein@lyra.org>
To: Jon Travis <jtravis@covalent.net>
Cc: dev@apr.apache.org
Subject: Re: apr_vformatter changes & optimizations
Message-ID: <20011001205154.B24906@lyra.org>
Mail-Followup-To: Jon Travis <jtravis@covalent.net>, dev@apr.apache.org
References: <20011001134355.A11996@covalent.net>
 <20011001160713.N24906@lyra.org> <20011001202817.A19784@covalent.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20011001202817.A19784@covalent.net>;
 from jtravis@covalent.net on Mon, Oct 01, 2001 at 08:28:17PM -0700

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/