Re: [hatari-devel] OS X performance problem

[Bob Carpenter <hatari@xxxxxxxxxx>]

Nicolas,

Actually, it is a US shareware game. However, in any case, I am not doubting your floppy disk timings. Eero was questioning why he was seeing shorter load times than I see when loading this game. Unfortunately, timing this on a real STE is not possible for me. Without Hatari, I would have had to leave my ST memories behind about 6 house moves ago. :) I looked for a YouTube Frantick video, but the only one I found did not include the 640K music file so the load time is not equivalent. 

With the latest Windows 1.8 development release and the status bar off, it takes 16 seconds to load in fast forward (frame skip=5). It was approximately the same time to load in fast forward with the status bar on in Windows. It takes approximately 4 minutes, 50 seconds to load without fast forward. I specifically used the Windows release to take the sub-par OS X SDL out of the equation.

My latest 1.8 OS X load times are as follows:
No statusbar
Fast forward - 29 seconds (frame skip=5)

Statusbar
Fast forward - 38 seconds (frame skip=5)

Because I am seeing the same timings in normal (non-fast forward mode), I am assuming the difference is due to the OS X SDL port. Since I do not see any effect in the gameplay, I think a few seconds extra to load a game in fast forward mode is perfectly acceptable. Hopefully, SDL 2 has an improved OS X port. However, I know there were some concerns about Hatari moving to SDL 2 so I am happy that the initial slowdowns have been resolved. At this point, they seem to be little more than benchmark differences. It has no effect on how the game actually plays and I think that is what is important.


Bob C


On Jun 3, 2014, at 4:46 PM, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:

> Le 03/06/2014 22:51, Eero Tamminen a écrit :
> "--fastfdc yes" option slightly decreases the time and with
>> "--statusbar off --drive-led off" it takes ~5 secs in STE mode.
>> 
>> In ST mode, module isn't loaded and startup takes 3 seconds,
>> regardless of statusbar i.e. it really seems to be related
>> to disk loading.
>> 
>> With Hatari v1.6.2, it takes 2-3s to start in *STE mode* with
>> statusbar i.e. it's considerably faster.  Either using ST mode
>> or disabling statusbar makes startup time into 2 secs.
>> 
>> 
>> I.e. the issue seems to be really related to disk load updates
>> and statusbar.  However, when I profiled it, statusbar update
>> took only 0.1% and screen drawing calling it only 0.7% of CPU.
>> This is expected because fast forward uses frame skipping.
>> 
>> (FDC interrupt handling, which isn't involved in CPU usage related
>> to statusbar updates, took 35% of Hatari CPU.)
>> 
> 
> Hello
> 
> For Bob,
> 
> I don't know this demo, but I'm pretty sure FDC timings are very-very accurate now. So, once statusbar is disabled, comparing with previous Hatari is not relevant (especially with 1.6.x where FDC timings were nearly all wrong)
> 
> The real test is to run this demo on a true STE and check the time it takes and compare with current Hatari (in case you don't have an STE, maybe there's a youtube video somewhere of the demo that you could use as a reference timing)
> 
> Nicolas
> 
>