Article Preview

FEATURE

Optimizing Xojo Apps

Some unexpected performance and memory implications

Issue: 15.4 (July/August 2017)
Author: Christian Schmitz
Author Bio: Christian Schmitz is the creator of the Monkeybread Software Xojo Plugins.
Article Description: No description available.
Article Length (in bytes): 14,286
Starting Page Number: 71
Article Number: 15407
Related Link(s): None

Excerpt of article text...

While working on several bigger client projects, I ran into some interesting performance issues. This includes things we learn about processor usage and how Xojo works internally. Some side effects can impact app performance if you don't know about them. You can use these techniques to improve your apps.

Slow App function

The app function in Xojo is quite slow. The implementation I expected personally was a simple read-only global variable. That's how the Cocoa frameworks handle NSApp. When the app starts, this variable is initialized, so before initialization in a Cocoa app in Xcode, NSApp can be nil. For Xojo, the app function never returns nil except inside the App.Constructor. Due to the App function being a function, it does some things for the runtime and costs time.

Properties and methods defined in the application class accessed via the app function have a performance hit due to the app function itself. My recommendation is to make those shared methods and shared properties whenever possible. The access of a shared property on the app class is about 20 times faster than going though the app function for a regular property.

Be aware that once you are inside a method (or event) in your app class, accesses to properties should go without app. prefix. Simply without or with self. prefix, you can quickly access other properties or methods.

Slow Session function

...End of Excerpt. Please purchase the magazine to read the full article.