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