Date:	Thu, 17 Oct 2002 07:46:48 +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.1D88N.H42NCC@pauzner.dnttm.ru>
Message-ID:	<Pine.SUN.3.91.1021017073456.3848B-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 Wed, 16 Oct 2002, Leonid Pauzner wrote:

> > Can you show a design for such caching?  Specifically, how do you know
> > when to invalidate the cached value(s)?
> 
> I mean a caching within an hour directly inside mktime(),

This only works for normalized `struct tm' arguments to `mktime', and 
doesn't test the timezone offset (so could produce erroneous results).  

Anyway, what applications do you think will benefit from this?  If you 
are thinking about those which call `stat' (like `ls'), what speedup of 
`stat' will this change get us (I'm not sure mktime takes up a 
significant portion of `stat's time)?

As for `gettimeofday', what kind of applications calls it so massively as 
to justify caching?  Isn't it better to move this caching into 
`gettimeofday' itself?

- Raw text -