- Joined
- Nov 25, 2007
- Messages
- 1,665
- Reaction score
- 13
- Points
- 38
- Location
- Germany
- Website
- www.enderspace.de
- Preferred Pronouns
- Can't you smell my T levels?
Regarding my rant about instability of Orbiter and what can be done about it, I'd like to address this paragraph:
It's also worth noting, that using only the mentioned debugging tool, you can also profile your code, by looping it and pausing its execution. If the cursor stops usually at the same branch of code, then statistically this is your bottleneck and you should investigate deeper there until you remove the bottleneck. Afterwards repeat the experiment. The method is described in detail here. I used it to speed up TransX' Auto-Min feature with great success.
Well, that's not valid anymore, because since MSVS 2013, MS added the Attach to Process option also in the Express (Freeware/Registerware) version! Maybe it's a good time to write an article what we all can do now for to improve the stability of our addons.Even without modifications of the Orbiter API, like in the above example, some simpler testing framework could be achieved, if only Orbiter was built with Free compilers, like MinGW, instead of MS-VC. Both MinGW and a full version of MS-VC allow for attaching their debuggers to an external process (Orbiter.exe), which allows you to find out which at least which DLL has caused the crash. The problem is, that you can’t debug code with MinGW which is not compiled by it, and a full version of MS-VC, that allows it, costs 600€. Who wants to waste so much money?
It's also worth noting, that using only the mentioned debugging tool, you can also profile your code, by looping it and pausing its execution. If the cursor stops usually at the same branch of code, then statistically this is your bottleneck and you should investigate deeper there until you remove the bottleneck. Afterwards repeat the experiment. The method is described in detail here. I used it to speed up TransX' Auto-Min feature with great success.
Last edited: