> >>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().)
Then get the time with microsecond resolution in the thread, but only save second resolution. This way, the 64-bit division is not happening in the middle of request processing. > > 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. Yes it is, but it isn't the ONLY valid remedy. Since that change is causing a lot of grief, I am asking us to consider other remedies. Ryan
