delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/10/16/02:02:15

Date: Wed, 16 Oct 2002 08:01:25 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Leonid Pauzner <uue AT pauzner DOT dnttm DOT ru>
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: <Pine.SUN.3.91.1021016075252.20518B-100000@is>
MIME-Version: 1.0
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

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019