Hi, On keskiviikko 17 huhtikuu 2013, Alan Hourihane wrote: > > However, gettimeofday(): > > * uses Tgettimeofday() on MiNT and Tgettime() & Tgetdate() on TOS. > > * Then it does mktime() which does timezone stuff, and if non-null > > value is given as timezone arg (like Quake does), it will also > > call timezone stuff directly. > > > > Currently it's assumed that this is the culprit for bad performance, > > it will hopefully be soon verified (by removal of this call & > > re-testing). > > mktime() is a very bad performer - known fact. One of the packages > I was building decided mktime() was too slow and deemed it unusable > because it took longer than 60 seconds (when compiled with m68000, > m68020-60 is quicker, but still slow.) Attached is a callgraph chart of where the performance goes when Doom draws a frame (version that still uses gettimeofday()). As localtime.o is lacking symbols, I have manually added time_fun_?? function symbols to places I saw in program disassembly to be function entry points within it. *_AA is the first address, *_HH is the last one (also in localtime.c source code, I assume). In the callgraph, "diamond" shaped nodes are for symbols which addresses are called as subroutines (by JSR or BSR), and ellipse shaped nodes are for symbols which code is called in some other way. - Eero Ps. That callgraph is generated from Hatari's profiler output with a post-processor script included with Hatari (in Mercurial repo) in case somebody's interested in optimizing software for Atari...
Attachment:
lindoom-frame.pdf
Description: Adobe PDF document