++1 here. Ryan
---------------------------------------------- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -----Original Message----- > From: David Reid [mailto:[EMAIL PROTECTED] > Sent: Monday, July 15, 2002 8:00 AM > To: APR Dev List > Subject: Re: Why not POSIX time_t? > > +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 > > > > > > > > > > > > > > > > > > >
