Why not POSIX timeval?

[Justin Erenkrantz <je...@apache.org>]

On Sun, Jul 14, 2002 at 11:03:45PM -0500, William A. Rowe, Jr. wrote:
> That is a more frequent case, yes.  How httpd stores the return
> values from apr functions is up to httpd.  If all it needs is elapsed
> seconds, and int suffices quite nicely.
>
> 
> E.g.
> 
>   int request_start = apr_time_as_sec(apr_time_now());
> ...
>   int request_end = apr_time_as_sec(apr_time_now());
> 
>   int elapsed_sec = request_end - request_start;

And, if we are trying to optimize the httpd case, I'm merely
saying that busec does a *really poor* job.

I'm beginning to think a timeval-like structure (perhaps two
64-bit scalars - one for secs and one for usec - in decimal) is
what we really want.  The time to access the second component becomes
free.  The precision is maintained with the usec structure.

(I could be convinced that it should be two 32-bit scalars which
matches POSIX.)

When optimizing, I think you need to know what you are optimizing
and I think the focus here is on optimizing the wrong functions.
I'm beginning to think we need to optimize the retrieval of
seconds at the possible expense of difference calculation.

> And apr_fileinfo_t ctime, mtime and atime become ... ints?

It's trivial to take a time_t and convert it to a timeval
structure.  So, I'm not sure what you are saying here.

> Glad to see we are staying on topic.  Interesting to see some who
> have folded their interest in the library project.

I have no idea what this is referring to.  Could you please
elaborate?  -- justin

Re: Why not POSIX timeval?

[rb...@apache.org]

On Sun, 14 Jul 2002, Justin Erenkrantz wrote:

> On Sun, Jul 14, 2002 at 11:03:45PM -0500, William A. Rowe, Jr. wrote:
> > That is a more frequent case, yes.  How httpd stores the return
> > values from apr functions is up to httpd.  If all it needs is elapsed
> > seconds, and int suffices quite nicely.
> >
> > 
> > E.g.
> > 
> >   int request_start = apr_time_as_sec(apr_time_now());
> > ...
> >   int request_end = apr_time_as_sec(apr_time_now());
> > 
> >   int elapsed_sec = request_end - request_start;
> 
> And, if we are trying to optimize the httpd case, I'm merely
> saying that busec does a *really poor* job.
> 
> I'm beginning to think a timeval-like structure (perhaps two
> 64-bit scalars - one for secs and one for usec - in decimal) is
> what we really want.  The time to access the second component becomes
> free.  The precision is maintained with the usec structure.
> 
> (I could be convinced that it should be two 32-bit scalars which
> matches POSIX.)
> 
> When optimizing, I think you need to know what you are optimizing
> and I think the focus here is on optimizing the wrong functions.
> I'm beginning to think we need to optimize the retrieval of
> seconds at the possible expense of difference calculation.
> 
> > And apr_fileinfo_t ctime, mtime and atime become ... ints?
> 
> It's trivial to take a time_t and convert it to a timeval
> structure.  So, I'm not sure what you are saying here.

I am more and more convinced that apr_time_t should stay exactly as it is,
and interval times should move to 32-bit values representing usecs.  If
httpd wants 1 second resolution, then they either take a performance hit,
or use POSIX time_t.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------