Mail Archives: djgpp-workers/2002/10/16/02:02:15
On Tue, 15 Oct 2002, Leonid Pauzner wrote:
> This will not help too much since other time functions
> patalogically ineffective also.
``Patalogically ineffective''? If you have proposals for more efficient
implementation, please tell what they are.
I'm not too much of an expert in this area (I just hacked around that
code for a while), but AFAIK the time computations are notoriously hard,
especially if you want to get them right. The only implementation I know
of that is faster than what we have is the one you find in djtzs203.zip:
it sometimes avoids looping for marginal values of time_t. That
implementation is very similar to what we use, though; we didn't switch
to that implementation due to legal issues.
> 3800 mktime() calls requires 130000 calls of days_to_years()
> which costs nearly the same as all getenv calls before your patch
> (while days_to_years could easily be cached from the previous call).
Can you show a design for such caching? Specifically, how do you know
when to invalidate the cached value(s)?
> Also, since time functions usually called in present
That's not a valid assumption. There are many programs that call time
functions for past and/or future dates.
> it may be reasonable to calculate seconds since the release day
> (or some date in 2002) and then add a constant distance from 1970,
> transparently to the user.
I don't think the distance from the epoch is an issue that affects
performance, but I might misremember what the code does. Are you saying
that computations for year 1971 are significantly faster than for year
2010?
- Raw text -