Performance improvements in Xojo

The last weeks were interesting as Xojo Inc.'s developer team picked up a few of the issues I filed about performance. You may benefit from them automatically as they improve things on the compiler, linker and framework.

Let's take a look:

1. IsEmpty

Recently I made a blog post pointing to various ways to check for a string being empty. Length is slow since it counts characters, while bytes is faster for just looking up the byte count. The String.IsEmpty function was using .Length and got updated to use .Bytes, so anyone using it, will get a speed increase when using it. The faster way stays to compare to "".
Other parts of the Xojo framework may internally call .len or .length to compare to zero and that could also be optimized.

74611 Optimize String.IsEmpty

2. UITrap

A few days ago I complained about all the calls to UITrap in the framework. That is to check if you are on the main thread before calling a GUI framework function. If you are not on the main thread, an exception is raised and you may have seen UITrap mentioned in some stack traces in your applications if you use threads. This function was a bit slow and Xojo Inc. got a new faster implementation.

74591 Make _UITrap faster

3. Web Framework

In my performance checks for web apps, I saw that simple framework functions spend more time on stack checking than on actual work. Sometimes taking over 90% of the time to do this stack housekeeping for a call. But now the web framework got audited and a lot of #pragma lines added in Xojo code parts, which makes quite a few calls faster.

71960 Make web framework faster by using #pragma StackOverflowChecking there

4. CEF Framework

For Windows, if you use a HTMLViewer somewhere, you may get the CEF DLLs added to your application. Now if you use our WebView2ControlMBS for Windows and the standard HTMLViewer for macOS in a cross platform project, you would get the CEF DLLs for Windows, even if you don't use them. Xojo could be updated to allow you to wrap the calls to the window with HTMLViewer in #if conditions and the linker will strip the window out and skip the CEF DLLs. You may have two windows, one for macOS and one for Windows and each uses a different way to show a website.

74568 CEF gets included even if the window is not referenced

5. Runtime Stack Check

We talked before about how stack checking can be expensive on macOS. So we asked Xojo Inc. to make it faster than they worked on it a few weeks ago!
The new stack checking is much faster, so all of the Xojo methods are a bit faster. Depending on your code, you may see an speed increase of a few percent since every little method call gets a bit quicker.

63667 Please make RuntimeStackCheck faster

6. Speed up CLong() function

Various functions in the Xojo framework convert string to number. The CLong() function showed up for me in some traces as taking a ton of time for converting text. This got improved since you don't need to convert encodings like UTF-8 to ASCII to read digits.

68962 Speed up CLong() function

7. Speed up background tasks

Xojo loops spend a lot of time with checking whether they should switch threads by calling RuntimeBackgroundTask. That function checks how much time passed using TickCount internally, which seems to be slow. By internally switching to another function on macOS and iOS, Xojo Inc. improved performance a lot here.

All applications doing loops (for, while or do) will speed up a little bit.

74649 Find something faster for RBTickCount

When?

These great changes may show up in one of the next Xojo releases. You never know how progress goes and when something is tested and goes into a release. Be sure to join the testers group to try them when available as a beta version.

More work

If someone at Xojo wants to do more, we got a few cases collected for you:

All of them may more or less improve both the IDE and the Xojo built applications.