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