Date:	Thu, 14 Jun 2001 11:19:25 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Yury A. Zaitsev" <yurick AT oblik DOT dp DOT ua>
cc:	djgpp AT delorie DOT com
Subject:	Re: __djgpp_map_physical_memory - some questions
In-Reply-To:	<tv58g9.vui.ln@nix-if1>
Message-ID:	<Pine.SUN.3.91.1010614111902.972S-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 13 Jun 2001, Yury A. Zaitsev wrote:

> >> Is DOS _really_ so slow?
> DD> No, but consider that Unix keeps track of the time *as* a time_t, so
> DD> time() merely reads a number from memory and returns it - a few CPU
> DD> cycles at best.  DOS, however, uses the hardware realtime clock, so it
> DD> must convert month/day/year/hour/minute/second/timezone to a time_t
> DD> each time you need to know what time it is.  The conversion is slow.
> 	Well, but why time() simply not caches this values (month/day/year/
> hour/minute/second/timezone) (such as Linux kernel does)?

This is not as simple as it sounds.  You cannot know whether a second
passed without asking DOS, and you cannot even rely on the timezone
being fixed, because the user can change the value of TZ in the
environment.

Even if you do cache the time for one second, you cannot simply add
seconds to the previous value of time_t, since the user can change the
system clock.

But if you have specific changes in mind, please send in patches
(please post them to djgpp-workers AT delorie DOT com).

>    I've tested mktime()'s speed just now and yes, you are right.
> mktime() is a bottle-neck of the time(). It takes about 70-80% of the 
> time()'s time :)

Converting calendar time to seconds since the epoch is not an easy
job.

- Raw text -