[Freemint-list] [MiNT] MiNTlib timing related functions behavior/performance

[Miro Kropáček]

Hi,

just a reminder for future generations, this is still a *huge* performance
killer. I've been bitten hard (again) by mintlib's gettimeofday() today.
I've been working on Atari800 emulator and I'd totally blame its new
features for being so awfully slow until I (by total accident) discovered one
innocent commit
<https://sourceforge.net/p/atari800/source/ci/8d70598add0ba116b4c8dd6d9e63de4a1bb11c55/>
which actually changed everything. So for past 9 years anybody trying to
compile atari800 for the mint target would just blame the emulator's
advanced features, nostalgically remember the times of 1.x versions which
used to work pretty nicely and move on.

With this patch reverted (and few other tweaks) I'm able to use atari800
2.2.0 version from 2011 without any trouble, with performance hardly
distinguishable from older 1.x builds.

Shouldn't we issue a warning when using that function?

On 4 May 2014 at 00:08, Alan Hourihane <alanh at fairlite.co.uk> wrote:

> On 05/03/14 12:03, Eero Tamminen wrote:
>
>> Hi,
>>
>> On keskiviikko 17 huhtikuu 2013, Andreas Schwab wrote:
>>
>>> Eero Tamminen <oak at helsinkinet.fi> writes:
>>>
>>>> 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.
>>>>
>>> ...
>>
>>> But mintlib should not be calling the localtime stuff for the timezone,
>>> this is meant to be the _kernel_'s idea of the timezone.  If MiNT does
>>> not keep track of a time zone gettimeofday should just return zero in
>>> the timezone argument.
>>>
>> Has somebody looked into this timezone stuff?
>>
>
> Not here. It's not high priority for me.
>
> gettimeofday() being unreasonably slow in MiNTlib is pretty nasty.
>>
>
> I agree it's nasty and should be fixed, but unless someone steps
> up it most likely won't be done.
>
> Alan.
>



-- 
MiKRO / Mystic Bytes
http://mikro.atari.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.atariforge.org/pipermail/freemint-list/attachments/20170623/71f02e84/attachment.html