apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: Why not POSIX time_t?
Date Mon, 15 Jul 2002 03:17:18 GMT
Ryan Bloom wrote:

>BTW, this whole conversation started because we wanted to speed up
>Apache.  Has anybody considered taking a completely different tack to
>solve this problem?  

If you mean using only second-resolution times, that's an option,
but not for the httpd.  One of the big problems with 1.3 was that
the request time was only stored with 1-second resolution.  We used
to have to add in custom, redundant time lookups to get better
resolution whenever we needed to instrument request duration or
log request times with higher precision.

>I know there is a patent on this, but I am willing to ignore it, and I
>am pretty sure that we can get the patent owner to let us use it.  (I
>won't say who owns the patent, but if the owner wants to stand up, it
>will be obvious why I say this).  We could create a separate thread to
>keep track of the current time every second.  That way, the computation
>is completely removed from request processing it is just a memory
>access.  On platforms without threads, we just go back to getting the
>time during request processing.  That will hurt performance for those
>platforms, but I am not too concerned about that.

What problem are you trying to solve with this separate
thread?  If it's "speeding up time lookups," I think the
effort is misguided, for two reasons:
  1. Many modern operating systems already have well-
     optimized implementations of gettimeofday() that
     don't involve much more than a read from a memory
     address that contains the current time.
  2. The gettimeofday() is fast compared with the real
     bottlenecks in time processing: expanding the time
     into a struct tm and formatting it in human-readable
     form.  (We've already solved both of these in 2.0
     with caching solutions, and the time code no longer
     registers as a significant expense in performance


View raw message