Brian Pane wrote:
> William A. Rowe, Jr. wrote:
>
>> Is this the right place to be caching, or should this become a
>> straightforward
>> optimization to apr's time.c functions? I'd think the advantages are
>> many for
>> keeping 15 current seconds in apr, and would pay off across the
>> board. Within
>> apr, we can always recalculate just the ms as well, for fun.
>>
> I think putting it in APR would work. The one limitation I can think of
> is that adding the cache in apr_explode_localtime() itself wouldn't be a
> win because we'd have to add the overhead of a gettimeofday() call to
> check whether the supplied time was indeed current (and thus susceptible
> to caching).
I'm not that familiar with the usage patterns of this function in Apache
et al, but it seems to me that a gettimeofday() call could be avoided
reasonably well by simply tracking the previously-used time argument.
If the current call is for a time which is later than the one of the
last call (within a certain margin), cache it. This should be just
about as effective as checking gettimeofday() (possibly moreso, as it
would also match anything within a reasonable proximity of the current
time). It might miss one or two if there are long periods without a
call, but in that situation it's arguable that the speed of this
function probably isn't the largest concern anyway.
Just a thought..
-alex
