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
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 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?