As the title says, is it possible to profile GCC-compiled executables on AmigaOS4.1 using an X1000 or Sam440?
I can't get GCC's built-in profiling (-pg) to work, it just crashes when the executable finishes on my X1000. I have been told that it should work on old AmigaOnes', but is probably not supported on X1000 or Sam440. (I have not yet tried Sam440.)
I tried using the program "Hieronymus", but it doesn't support the X1000. The readme seems to indicate it will work on the Sam440... is this really my only option?!?
P.S. Currently my Sam440 is out of action, so I'd really rather another option.
@ChrisH
Which is your exact need?
@Massi
I wasn't aware that "profiling" had multiple meanings... I want to find out why my program is extremely slow performing a particular activity, which uses a custom-written multi-layered abstraction. So ideally I want to see which procedures/methods it is spending most of it's time in. Simple call counts would not probably be sufficient, unless I *really* screwed up, but I guess that would be better than nothing...
The operations involved typically have complex side-effects (file/memory modification), so I can't easily duplicate operations to see how that effects total run time.
Author of the PortablE programming language.
I love using Amiga OS4.1 on my X1000 & Sam440 :-D
@ChrisH
Did you think of getting the execution times of the suspicious routines?
Get the system time at the beginning (T1) / end (T2) of a given routine f() and calculate the elapsed time (T2 - T1).
I would also unroll heavy loops, if any.
@Massi
The difficulty is knowning where to start. Yes it would be possible, but very laborious to narrow down the problem (similar but worse than using PrintF for debugging crashes!). A profiling tool would save a LOT of effort, hence why I'm checking that I haven't overlooked such a tool.
A profiling tool would also be very handy for any future efforts I might make to optimise PortablE further.
Author of the PortablE programming language.
I love using Amiga OS4.1 on my X1000 & Sam440 :-D
@ChrisH
Unfortunately when it comes to such tools there is an evident obsolescence.
My advice is to isolate suspicious parts and investigate them. Also code reviews could help, but I guess you are the only developer.
@ChrisH
Never knew there were tools available for that, so I devised my own sort-of, which, when in DEBUG-mode, does nothing more then print a message when a function is entered containing the function's name and print a simmilar message when that function is left again. It is achieved by a pair of macro's which are active only when DEBUG is defined. It even tells which level of nesting is reached.
It's a simple construction but it makes you aware which function contains the slow code.
Iteratively calling of functions and nesting or recursing, of declaring variables MAY be slowing things down considerably.
When you need a hammer to drive a nail home, but can't find one, a shoe's heel may not be the first choice but may come in handy anyway.
OldFart