Profiling a bmx program

BlitzMax Forums/BlitzMax Beginners Area/Profiling a bmx program

Doc Holliday(Posted 2011) [#1]
Hello,

in another post on this forum ( http://blitzbasic.com/Community/posts.php?topic=93169 ) I saw that the user col did a profiling
for the code posted there.

I am new to bmx and interested in how to do such a profiling. Is there any software out there for this task?

Thanks in advance

Doc Holiday

Last edited 2011


matibee(Posted 2011) [#2]
From my framework code:



Usage sample:




Doc Holliday(Posted 2011) [#3]
@matibee: Thank you very much - that's a great start and works fine. :-)

Anybody out there with more/other solutions? If so, I would like to hear from you ...

Doc Holliday


Czar Flavius(Posted 2011) [#4]
I just store the current MilliSecs before and the MilliSecs after the functin/code fragment, and output the difference. This gives you the time in milliseconds it took to peform. It works for quick and dirty comparisons of different ways of coding something. You may have to (perhaps redundantly) repeat the code a few hundred or thousand times, as a single go may complete in less than 1ms and make it impossible to meainingfuly compare.


GfK(Posted 2011) [#5]
I just store the current MilliSecs before and the MilliSecs after the functin/code fragment, and output the difference. This gives you the time in milliseconds it took to peform. It works for quick and dirty comparisons of different ways of coding something. You may have to (perhaps redundantly) repeat the code a few hundred or thousand times, as a single go may complete in less than 1ms and make it impossible to meainingfuly compare.
Same. My code is riddled with:
'Local S:Int = Millisecs()
blahFunction()
'DebugLog Millisecs() - S
I just take them all out at the end.


Perturbatio(Posted 2011) [#6]
I just take them all out at the end.

Just out of curiosity (I can't test it just now), but does BMax produce assembly for code wrapped in an if statement that depends on a constant condition that doesn't occur?

i.e.
const PROFILE_ON = false

if (PROFILE_ON) then
Local s:Int = Millisecs()
endif

blahFunction()

if (PROFILE_ON) then
Local s:Int = Millisecs()
endif




Jesse(Posted 2011) [#7]
yes it does. the only thing that controls binary code creation is compiler directives.


Perturbatio(Posted 2011) [#8]
yes it does. the only thing that controls binary code creation is compiler directives.


As I had suspected, but I was hoping it would optimise the code a little.


Jesse(Posted 2011) [#9]
it does some. just not to that level.


Doc Holliday(Posted 2011) [#10]
But conditional compiling with ?debug should do the job:

?debug
Local s:Int = Millisecs()
?

blabla_func()

DebugLog(string(MilliSecs()-s))


So you don't have to remove all the MilliSec()-statements. When you want to compile "clean" (without all the timing-code) you only have to compile in release-mode.

Last edited 2011


Perturbatio(Posted 2011) [#11]
But conditional compiling with ?debug should do the job:


Except that profiling your code in debug mode is not likely to give you the results you want.


matibee(Posted 2011) [#12]
Except that profiling your code in debug mode is not likely to give you the results you want.


I agree.

The code I posted above is actually the low level stuff. I wrap it with other functions that only call the profiling code when profiling is enabled...

Global _ProfilingEnabled:Int = False
Global _ProfileOutput:String 
	
'-----------------------------------------------------------------------------
Rem
bbdoc: Turn on application profiling
about:
End Rem 
Function EnableProfiling ( outfile:String )
	_ProfilingEnabled = True
	_ProfileOutput = outfile
End Function  
'-----------------------------------------------------------------------------
Rem
bbdoc: Enter a section of code to be profiled.
about:
End Rem 
Function EnterProfileSection ( name:String )
	If ( _ProfilingEnabled ) mbmEnterProfileSection( name )
End Function  
'-----------------------------------------------------------------------------
Rem
bbdoc: Exit a section of code to be profiled.
about: The profiler will keep track of the number of times this section of code
has been called and the time (in milliseconds) of each call.
End Rem 
Function ExitProfileSection ( name:String )
	If ( _ProfilingEnabled ) mbmExitProfileSection( name )
End Function  


As you can see it's got very little overhead when profiling is not enabled so it's pretty safe to leave all the profiling calls in your production code.

Last edited 2011


col(Posted 2011) [#13]
@Doc Holliday

I use a similar code and idea to those suggestions here expect that i load a Bmax file and process it to create another Bmax file ( named with '***_profile.bmx' on the end, the *** is the original filename ) with the function calls in place. It just saves me having to manually type in the function calling etc for each program. You can imagine that manually editing someone elses source code, and even your own, can be time consuming. So I get Bmax to do it for me in a fraction of a second :-)

Its as easy as loading a file then loading and compile the '***_profile.bmx' version that then spits the results out. Debug mode OFF of course.

Dave


Czar Flavius(Posted 2011) [#14]
It's not very time consuming for me because I don't spend a lot of time doing it. I only do it when something is going slow and I can usually rule out most functions.