One of Xojo’s features we’ve focused on improving recently is the Profiler. For me, the work has been immensely useful as it has permitted me to hunt down certain code paths that were quite slow.
We had tried doing this with the old profiler, but it was not fruitful becuase all the old profiler told you was that method X got called X many times and that in total it took so many milliseconds. What it could not reveal was that certain code paths that called the same low level routines were quick, and that others were slow. And the profiler itself added so much overhead that profiling the IDE was painfully slow. You could start a profile session & make coffee, go cut the grass. walk the dog, feed your animals, have lunch, have a nap, make some more coffee and in a long while later the IDE might be at the NewProject dialog.
Xojo’s Profiler is much, much quicker and the IDE launches fast enough with it on we can actually use it to profile the IDE. But the big difference is the data collected.
Xojo’s Profiler allows us to see individual code paths and focus on the ones that are slow and then determine why those paths are slow.
And that is just what I did recently. Using the Profiler I could see exactly what code paths and functions were slow and where all the time in start up was accumulating. Focusing on a small number of methods, we’ve been able to shave a LOT of time off the start up. Nearly 50% when we run a debug version of the IDE!
You’ll see the impact all over the IDE – for example, without doing anything to the layout editor, web layouts that use a lot of containers immediately work better. That’s not to say we aren’t going to spend more time there – just that the side effects of some optimizations we’ve done are widespread. Compiling even seems to be faster as a result.
Watch for all this when Xojo 2014r1 lands!