Preprocessor profiling now more advanced
Community Forums/Showcase/Preprocessor profiling now more advanced
| ||
| I just spent the last two hours improving my preprocessors code profiling abilities. Each function now has its own HTML file, for now it only contains fastest and slowest function calls, but this will probably change soon. Why am I doing this? The answer is Juno. My preprocessor has already identified four separate functions that took way too much CPU time than they should have, and they are fixed now. I want to continue to optomise it, but to do that I need better tools. The future of this profiler is not as a part of my preprocsesor, it is as a separate DLL, callable from any language that supports DLL calling. It is simply too messy including it in the preprocessor. It may well be a good time to invest in a copy of PureBasic. The downside? Such a solution will probably either not be free or not be released. But for now, the preprocessors profiler will have to do. An update will be out whenever I get around to it, along with some other misc features. I actually believe I released version 5.0 prematurely before, but these are the added features: /* Changes Since 5.0 * Fixed a #Macro bug [I now clear out the conditional stack, what a mistake!] * Fixed a #Define bug * Added Enum * Fixed a bug where double spaces between Function and the Function Name will interfere with profiling * #ProfileNoFunctions * #ProfileSection [Section] * #EndProfileSection * #Clamp Variable, Low, High * Profiling now includes a separate HTML page per function. * * ProfileSections don't do any funky stack based things and so they have to be placed without overlap in terms of source position */ I'm off to optomise Juno! |
| ||
| Hmmm.... the Clam Variable bit is almsot enough on it's own to get me to pick this up. I'll have to take more of a look at it since im sure theres alot more too it ;). |
| ||
| It added up to around 9 functions which were causing severe bottlenecks (most involved the FonText fucntions or freeing entities). Juno is as smooth as all hell now, my preprocessor now has my respect! |
| ||
| The profiler has been a massive help to me. Not only has it made me organise my code much more effectively, but it's helped me no end with finding slow functions. Top work! |
| ||
| This is great, thanks. |
| ||
| It gives me application error when trying to compile... "The application failed to initialize properly (0x0000135)" I'm running Windows XP. |
| ||
| Just out of interest, what FONText functions were causing slowdown? |
| ||
| Bouncer - have you installed the .Net runtimes? Mr Blonde - The fontext functions for freeing layers deleted an instance of a type with a BlitzArray inside, which causes massive slowdown. This isn't the fault of the FonText code, I believe this is a Blitz bug (check out my post on the bug forums). |
| ||
| No... didn't know it was required. Downloading now.... 24.2 megs.... this is gonna take for ages with my ISDN... :( |
| ||
| How do you think I feel, downloading the SDK on my 56k? :) |
| ||
| I just rewrote the Blitz portion of the profiler, completely untwining it from the preprocessor. It uses radically different methods to figure out time in the function, and should hopefully provide a *much* clearer picture of what is going on. In the following example, MiscFunction recieves a total call time of 0 because the time is 'allocated' to the delay function rather than them both. Which allows you to find out how much time the program spent in the actual function itself, rather than calling another function from it. Very cool compared to the old preprocessor. The lib will work with normal Blitz though obviously you would want to use the preprocessor so you don't have to go through all the trouble of registering your functions etc. Profiler_Init( ) Global MiscFunction_ID = Profiler_RegisterFunction( "MiscFunction" ) Global DelayFunction_ID = Profiler_RegisterFunction( "DelayFunction" ) For Count = 1 To 10 MiscFunction( Count ) Next Profiler_Write( "code_profile\" ) Function MiscFunction( Count ) Profiler_PushFunction( MiscFunction_ID ) DelayFunction( Count ) Profiler_PopFunction( MiscFunction_ID ) End Function Function DelayFunction( Delay_Time ) Profiler_PushFunction( DelayFunction_ID ) Delay Delay_Time Profiler_PopFunction( DelayFunction_ID ) End Function |
| ||
| Michael - why were you freeing a FONText layer so often? |
| ||
| I have random text that isn't part of the hud that comes and goes. If it were not for the Blitz bug the method would have been plenty fast (and still is). |
| ||
| @Michael Reitzenstein I'm new of this post (lost 4 months mails and posts) Please... now that you have consolidate some awesome features of your preprocessor... - Can you improve the documentation with some samples and codes? I've downloaded the zip file but there isn't any kind of documentation.. - There is any possibility to see your preprocessor in some new blitz ide (blitzView, protean, etc)? - What are the new features that you will implement? Ciao Gianluca |
| ||
| - Can you improve the documentation with some samples and codes? I've downloaded the zip file but there isn't any kind of documentation.. Nope - there is the documentation on the web site, but that's it. I don't get any financial compensation to work on the preprocessor and documentation is just something that I hate doing. - There is any possibility to see your preprocessor in some new blitz ide (blitzView, protean, etc)? It already does. - What are the new features that you will implement? Whatever I feel like - the source is included with the release so anybody who wants certain features can implement them themselves. |
| ||
| Michael - an easy solution to this is to either hide/show the layer *OR* you can delete the surface belonging to the layer and rebuild. |
| ||
| Michael - an easy solution to this is to either hide/show the layer *OR* you can delete the surface belonging to the layer and rebuild. It would be, if there were a set number or limit on the text. Pooling them is overkill and probably wouldn't end up much faster at all. |
   |