|Re: [hatari-devel] Opinions on Hatari profiler "user interface"?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
I use it a lot now with my current new dev.
essentially profile cycles and profile counts
Would it be possible to add the instruction disasm just after the PC,
count: and number of hits
Something like :
> profile counts
0x05ce14 5.38% 134638 move.l d0,(a0)
0x05ce18 5.38% 134638 nop
> profile cycles
0x05ce14 7.96% 1886852 addq.w #7,d3
0x05ce26 7.95% 1886318 lea 10(a0),a3
0x05ce20 7.95% 1886268 movem.l (a5)+,d0
My examples are totally stupid and just here for the example :)
With this, I could see in one look which instructions are concerned
instead of doing many times
To have a look at the instructions.
Best regards, this profiler is really a nice feature.
Le 03/04/2013 19:15, Eero Tamminen a écrit :
Hatari's profiler has gotten quite a lot of functionality
and its help text in the debugger has gotten quite long:
'profile' - profile CPU code
Usage: profile <on|off|stats|counts|cycles|misses|symbols|callers|
'on' & 'off' enable and disable profiling. Data is collected
until debugger is entered again at which point you get profiling
statistics ('stats') summary.
Then you can ask for list of the PC addresses, sorted either by
execution 'counts', used 'cycles' or cache 'misses'. First can
be limited just to named addresses with 'symbols'. Optional
count will limit how many items will be shown.
'addresses' lists the profiled addresses in order, with the
instructions (currently) residing at them. By default this
starts from the first executed instruction, or you can
specify the starting address.
'callers' shows (raw) caller information for addresses which
had symbol(s) associated with them.
Profile information can be saved with 'save'.
I hope people have by now had time to try this functionality,
hopefully also the recently added caller information tracking.
Do you have any opinions on how the profiler is used? Is there
something that could be improved, or think that it would work
better in some other way?
For example, currently:
* profiler will track caller information if symbols are loaded, but that
will slow down the emulation noticeably because it needs to do more work
for each instruction.
* if one wants to do profiling, but doesn't want caller information
tracking due to the slowdown, one needs to drop symbols before profiling,
if symbols are loaded. And if one wants to see symbol information when
viewing disassembly that contains profiling data, symbols need to be
re-loaded after profiling.
I'm wondering should I add some option/command for whether caller
information tracking is enabled or not? Any opinions on this, and if
yes, what such new option/command should look like, if it's added?