Bill Stoddard wrote:
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.
I'm opposed to his approach because it combines the worst of
both worlds: poor performance and poor accuracy.
Under this proposal, the sequence of time operations in an
httpd request would look like:
1. gettimeofday
(fast, no loss of accuracy)
2. 64-bit multiplication to build an apr_time_t
(slow (on lots of current platforms), no loss of accuracy)
3. 64-bit shifts to get approximate seconds
(fast, but loss of accuracy)
We end up with compromises in both performance and accuracy,
in code that:
- is completely under our control, and
- wouldn't require any compromise of performance or accuracy
if we just stopped creating the seconds*1000000+microseconds
representation in step 2.
Things look even worse outside the httpd. Cliff, for example,
mentioned in one of the threads last week that he uses apr_time_t
in programs that require microsecond resolution with high performance.
As long as we keep encoding apr_time_t in the current manner, APR will
never be an effective choice for such apps.
--Brian
