William A. Rowe, Jr. wrote:
At 06:36 PM 7/15/2002, David Reid wrote:
Can we all come down off the ceiling for a bit and get our feet back on the
ground?
I can't help but wonder why we are making this whole thing so complicated
when people have been using computers and libraries using time quite happily
for a number of years without getting as involved as this has gotten. But
then maybe I've borrowed some of Cliff's crack?
BTW, this is getting embarrassing to watch - please can we bring this to a
head somehow?
Would my unequivocal veto of any change to apr_time_t help?
Based on the data that we have so far, it wouldn't help. The current apr_time_t implementation isn't adequate for use in the httpd, based on the performance profile data that shows the 64-bit divisions to be a bottleneck.
It would be nice to say, "no problem, we'll just extract the seconds right after we look up the request_time, and we'll use the seconds value instead of the apr_time_t for everything after that." But that won't fix the problem. We deal with multiple timestamps in a typical request, not just r->request_time, and they all incur the 64-bit division costs. (For example, we need to format the mtime of the delivered file for use in the last-modified header. APR does a 64-bit multiplication to pack the time into an apr_time_t, and the httpd then has to do a 64-bit division to unpack the seconds field.)
--Brian
