Re: [hatari-devel] OS X performance problem

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Eero,

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

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
> 
> 




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/