apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: cvs commit: apr/time/win32 time.c
Date Mon, 05 Aug 2002 05:00:06 GMT
At 11:25 PM 8/4/2002, Ryan Bloom wrote:
> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> >
> > At 05:05 PM 8/4/2002, Aaron Bannert wrote:
> > >On Sun, Aug 04, 2002 at 06:29:34PM -0000, wrowe@apache.org wrote:
> > > > wrowe       2002/08/04 11:29:33
> > > >
> > > >   Modified:    include  apr_time.h
> > > >                time/unix time.c
> > > >                time/win32 time.c
> > > >   Log:
> > > >     Time in exact ms intervals can be very useful in
>benchmarking...
> > this
> > > >     patch defines a general API for doing so if the platform
>supports
> > > >     toggling the clock resolution.  Don't recommend doing so for
> > HTTPD,
> > > >     but flood and ab should appreciate it.
> > >
> > >If APR can't guarantee a certain precision across the board, how will
> > >that API be useful?
> >
> > APR cannot guarantee anything.  We have too many platforms.  The point
> > of this API is that win32, perhaps others, have more than one
>granularity
> > of time.  Your question should be, if we can't guarantee a certain
> > precision across the board, how are ab or flood useful?  I'd argue
>they
> > only provide insufficient resolution, and if there is an api to toggle
>it, > this new function exposes that API.
>
>I disagree.  When APR was started, we only provided functions that could
>reasonably be implemented on _most_ of our platforms.  IMHO, if we can
>find other platforms that can reasonably implement this feature, then we
>should keep it, but if we can't, then this function should go.

And our API defines time resolution in a 1us units.  This function simply
guarantees that if a platform can improve it's apr_time_now() resolution
-towards- 1us units, than it should do so for the duration of the pool [which
will generally be the lifetime of the process, if you call with the base or
global pool.]

Great for benchmark timings, worthless for HTTPD.

So, find another place to put this platform specific anomaly, such as a new
argument to the apr_initialize fn [which I REALLY didn't want to change]...
or this fn needs to remain.  In case you didn't get the gist, from a 
performance
perspective it's not a change you want to make for every apr application.

Bill



Mime
View raw message