+1 from me. Let's finish this nonsense! david
> New proposal... leave apr_time_t exactly as it is. The performance problem > is with how we are converting an apr_time_t into a value with 1 second > resolution (ie, doing 64 bit divisions). I propose we introduce some new > macros (or functions) to efficiently remove resolution from apr_time_t and > do an approximate (not precise) conversion to seconds. Aaron (I believe) > has already demonstrated this idea. This is the least invasive, easiest to > understand and workable solution IMHO. > > Bill > > > > >>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 > > > > > > > > > >
