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 [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
