|Re: [hatari-devel] OS X performance problem|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On sunnuntai 01 kesäkuu 2014, Bob Carpenter wrote:
> I am sorry for not doing the tests with the status bar off. Here are the
> 1.7 devel
> Fast forward - 25 sec
> Normal - 4 minutes 54 seconds
> 1.8 devel
> Fast forward - 8 seconds
> Normal - 4 minutes 57 seconds
For me, it loads in ~7 secs with fast forward even with statusbar enabled..
And without fast forward, the loading from (HD) floppy image takes:
~10 secs from clicking the program icon until FRANTRAK data loading starts
~20 secs to load FRANTRAK
~30 secs of different info screens until game gets to start screen
= 1 minute in total.
This is under 4MB STE emulation, with:
* Frantick (c) 1994-95 Dave Munsie *
* V 1.1 - Release date 01/03/1995 *
(Above is game's output with "-conout 2".)
Which version of Frantick takes 5 minutes to load?
> 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