|Re: [hatari-devel] Is it me or the new hatari release is slow ?
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
I understand the general idea behing bisect, but I've never used it yet.
Can you tell me the essential commands :
How to start
how to "bisect" an older version ?
how to "bisect" an intermediary version
I'll try to take some time this afternoon to do this.
Le 01/06/2014 10:18, Eero Tamminen a écrit :
On sunnuntai 01 kesäkuu 2014, Laurent Sallafranque wrote:
I've dowloaded the 1.7.0 sources from Hatari download section and
compiled them. So:
- my effect on my real falcon (VGA mode) is 10 FPS
- my effect on hatari 1.7.0 (new CPU) is 10 FPS
- my effect on hatari 1.8.0 (new CPU) is 6 FPS
From here, the new release consumes a lot of cycles that should not be
Both Git and Mercurial have support for bisecting regressions.
See the "bisect" command in "man hg".
If you can provide a test that returns error code when
regression is entered, Git & Mercurial can do the whole
bisection for you (that assumes none of the bisected
versions it tries to test have build issues).
To help with that, I was thinking that I could add new NatFeats
command which allows emulated program to tell Hatari to exit
with given exit code.
I.e. you only need to write an Atari program that detects
the regression, and "hg bisect" will get from Hatari
the information whether the version it tested does have
the regression or not.
I don't have right now time to write it, but I'll do it
If the issue is something that Hatari itself can easily detect,
you could for every tested version add patch to Hatari that
does the detection and exits Hatari with suitable exit code.
And then write few line shell script that does Hatari patching,
building and forwarding of Hatari's exit code back to Mercurial.