Date: Wed, 16 Oct 2002 08:01:25 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Leonid Pauzner cc: djgpp-workers AT delorie DOT com Subject: Re: libc' ctime.c optimizations In-Reply-To: <2.7.9.1KWON.H418CY@pauzner.dnttm.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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?