Debug Speed
BlitzMax Forums/BlitzMax Programming/Debug Speed
| ||
| Debugging my big game is UNBEARABLY slow. But when I start a new project with only a few things, it becomes very fast. Does anybody know of any code pitfalls that makes the debugger go slower? Too many global variables? Too many types? The functions themselves don't have many local variables, but I have some types which have a lot of fields. Are these loaded by the debugger, even if the node is not expanded? By unbearably slow I mean UNBEARABLE. I have given up on stepping through my code to find problems. |
| ||
| I don't know how helpful this might be but I found out that by incorporating all of my files as import files I was able to debug with more efficient speed than by using Include and by keeping all of my files under 1000 lines works good for debugging. I also have to have all of the project files I created in the IDE while debugging because sometimes the IDE does not load the exact file where the error is (any body have a clue?) . I don't know how big your project is but my biggest project is about 11K lines of code which might not be nearly as much as yours but those are my observations based on my experiences. that's with the default BlitzMax IDE. Ziggi's IDE might be better at dealing with large files but I personally don't know as I have used the demo very few times. |
| ||
| What kind of code is it? ie just lots of code in general or are there some nasty nested loops/branching in there etc? Would probably help knowing that. Im pretty clueless when it comes to how the max debugger works, but i do have some personal experience where a release compile benchmark finishes near instantly but a debug compile just wont go anywhere.. That was quite some time ago so i dont really remember what the code was about tho.. |
| ||
| The compile speed is fine and I might have up to 10 functions depth? I'm using Blide which I notice includes the files rather than import. He has added a feature to turn off the debug tree window so I can step faster, but it still goes fairly slow which I am guessing is down to the debug outputter. By looking at the raw output, I have noticed that constants and globals are outputted for every nested function?? I am going to try putting them in a type to see if that helps matters. |
| ||
| I would be most interested if the debugger is outputting more than is required. Also debugger is not cropping ultra large strings which could be a significant problem for some apps. If you do have large strings in your app you may want to add the following 1K limit to brl.mod/appstub.mod/debugger.stdio.bmx [263] and rebuild modules:
Case Asc("$")
p=(Byte Ptr Ptr p)[0]
Local sz=Int Ptr(p+8)[0]
If sz>1024 sz=1024 'try adding this line if big strings r causing debugger to crawl
Local s$=String.FromShorts( Short Ptr(p+12),sz )
Return DebugEscapeString( s )
Last edited 2010 |
| ||
| Pipes on windows have a performance problem when they raise 4 Kbytes if both the 'outputing' application and the 'reading' application do no flush them. BlitzMax does this properly but very long strings could make the debuger pipes hit the 4Kbytes limit... ? Try what skidracer suggests, it may be very useful. |
| ||
| We can customise the debugger??????????????????????? What else can I change? Long strings might be the cause of the problem, I will check. What does the NoDebug keyword do? Can I use it to compile an imported module as Release mode? I am using TimelineFX particle module, which goes really slow in debug. If I can make that compile as release, it would make me 58432048234093247198203092 times happier as a person. |
| ||
| It's still slow. Here is a sample debug output. Notice the constants and globals are repeated often. Should I put them into a Type? |
   |