Re: [hatari-devel] OS X performance problem

[Bob Carpenter <hatari@xxxxxxxxxx>]

Eero,

I am sorry for not doing the tests with the status bar off. Here are the numbers:

1.7 devel
Fast forward - 25 sec
Normal - 4 minutes 54 seconds

1.8 devel
Fast forward - 8 seconds
Normal - 4 minutes 57 seconds

Since I was using the stopwatch on my mobile phone, I would not worry about a few seconds. It does appear that the status bar has an effect in fast forward mode. However, when the system is running normally, it does not appear to have an effect.


Bob C

On Jun 1, 2014, at 3:01 AM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

> Hi,
> 
> On sunnuntai 01 kesäkuu 2014, Bob Carpenter wrote:
>> I decided to load the PD game Frantick with its 640K music track into
>> memory from floppy disk. I thought that would be a good bench test since
>> it has to read the floppy disk for a long time before the startup screen
>> appears. Back in 1995, the author recommended loading it on a hard disk
>> if you were going to use the music track.
>> 
>> Anyway, here are the numbers:
>> 
>> In fast forward mode:
>> 1.7 devel version (no track information) - 21 seconds
>> 1.8 devel version (track information) - 58 seconds
> 
> Do you see same difference also with statusbar disabled
> (--statusbar off)?
> 
> * If you still see the difference, it's not because of statusbar,
>  but something else, most likely Nicolas' FDC emulation improvements.
> 
> * If difference disappears with statusbar, then the slowdown is
>  due to statusbar and needs to be looked into.
> 
> 
> 	- Eero
> 
>> In real time mode:
>> Both 1.7 devel and 1.8 devel finished in 4 minutes 57 seconds
>> 
>> I do not know of many ST programs that accessed the disk during gameplay.
>> Back when I had my 1040 with only a floppy drive, I would have thrown
>> the disk across the room if it was accessing the disk while I was trying
>> to play the game. Obviously, some games access the disk between levels
>> (Zany Golf comes to my mind). If a game or demo was accessing the disk
>> while running, I could see how the track information could slow things
>> down. I just do not have examples of programs that are running and
>> accessing the disk at the same time.
>> 
>> If you are only updating the information when it actually changes, I do
>> not see how you can really improve this. The only other option would be
>> to make the track information display optional. That way, OS X users
>> that had problems with it could turn it off and they would be no worse
>> than if they ran 1.7.
>> 
>> 
>> Bob C
>> 
>> On May 31, 2014, at 5:11 PM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
>>> On lauantai 31 toukokuu 2014, Bob Carpenter wrote:
>>>> I have only started using the devel version with the changes you made.
>>>> It is running fine. I did not see any improved performance, but the
>>>> performance was fine on Hatari with the previous version. Your
>>>> changes may very well help users with older Macs though.
>>> 
>>> It's not related to how slow machine you have, but what you're
>>> testing.
>>> 
>>> First fix I did was to do statusbar updates only when something
>>> changes.  Now I fixed the case where statusbar actually changes.
>>> 
>>> I.e. you need a test case that causes constant updates to
>>> statusbar state, something that does constant disk accesses.
>>> 
>>> 	- Eero
> 
> 
>