Date: Thu, 14 Jun 2001 11:19:25 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Yury A. Zaitsev" cc: djgpp AT delorie DOT com Subject: Re: __djgpp_map_physical_memory - some questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.