delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/10/17/01:47:18

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 -


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