apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject Re: Why not POSIX time_t?
Date Mon, 15 Jul 2002 05:23:46 GMT
On Sun, 14 Jul 2002, Brian Pane wrote:

> 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.

But http only requires 1 sec resolution.  If you want better than that,
then you will have a performance hit.

> >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
>      profiling.)

Okay, now I am really confused.  The reason for changing apr_time_t was to
fix a performance problem in httpd, namely the 64-bit division.  But what
you just said is that time code is not a performance problem.  So, why are
we optimzing this again?


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

View raw message