[EMAIL PROTECTED] wrote:
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.
No you won't. It's *faster* to get the time with
microsecond resolution than to get it with second
resolution. (gettimeofday() is faster than time().)
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.
Right, and that problem still remains.
But what
you just said is that time code is not a performance problem.
No, I said the retrieval of the time (the thing for which you're
proposing a separate thread) is not a performance bottleneck.
So, why are
we optimzing this again?
Because 64-bit divisions are a performance problem, as
seen in FirstBill's recent benchmarks.
Looking up the time with microsecond resolution is not
the problem. The problem is that we do gratuitous 64-bit
math once we've retrieved the time. And the binary
microsecond change is a valid remedy for that problem.
--Brian
