apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: Why not POSIX time_t?
Date Mon, 15 Jul 2002 05:57:36 GMT
rbb@apache.org wrote:

>On Sun, 14 Jul 2002, Brian Pane wrote:
>
>  
>
>>Ryan Bloom wrote:
>>
>>    
>>
>>>BTW, this whole conversation started because we wanted to speed up
>>>Apache.  Has anybody considered taking a completely different tack to
>>>solve this problem?  
>>>
>>>      
>>>
>>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().)

>>>I know there is a patent on this, but I am willing to ignore it, and I
>>>am pretty sure that we can get the patent owner to let us use it.  (I
>>>won't say who owns the patent, but if the owner wants to stand up, it
>>>will be obvious why I say this).  We could create a separate thread to
>>>keep track of the current time every second.  That way, the computation
>>>is completely removed from request processing it is just a memory
>>>access.  On platforms without threads, we just go back to getting the
>>>time during request processing.  That will hurt performance for those
>>>platforms, but I am not too concerned about that.
>>>
>>>      
>>>
>>What problem are you trying to solve with this separate
>>thread?  If it's "speeding up time lookups," I think the
>>effort is misguided, for two reasons:
>>  1. Many modern operating systems already have well-
>>     optimized implementations of gettimeofday() that
>>     don't involve much more than a read from a memory
>>     address that contains the current time.
>>  2. The gettimeofday() is fast compared with the real
>>     bottlenecks in time processing: expanding the time
>>     into a struct tm and formatting it in human-readable
>>     form.  (We've already solved both of these in 2.0
>>     with caching solutions, and the time code no longer
>>     registers as a significant expense in performance
>>     profiling.)
>>    
>>
>
>Okay, now I am really confused.  The reason for changing apr_time_t was to
>fix a performance problem in httpd, namely the 64-bit division.
>

Right, and that problem still remains.

>  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.

--Brian



Mime
View raw message