Test 1

Var rs As rowset = SQLiteDatabase1.SelectSQL("SELECT invoices.invoiceno, invoices.invoicedate, invoices.invoiceamount, customers.firstname, customers.lastname FROM Invoices JOIN Customers ON invoices.customerid = customers.id")
Results1.RemoveAllRows
Var grandTotal As Integer
Var totalIterations As Integer  = 10
For i As Integer = 1 To totalIterations
  Var start As Integer = System.Microseconds
  For Each row As databaserow In rs
    ListBox1.AddRow(rs.Column("InvoiceNo"), rs.Column("lastname"), rs.Column("firstname"), rs.Column("InvoiceDate"), rs.Column("InvoiceAmount"))
  Next
  Var stop As Integer = System.Microseconds
  Var total As Integer = stop - start
  grandTotal = grandTotal + total
  Results1.AddRow("Test " + i.ToString + ": " + total.ToString)
Next
Var avg As Integer = grandTotal / totalIterations
results1.AddRow("Average: " + avg.ToString)

Test 2

Var rs As rowset = SQLiteDatabase1.SelectSQL("SELECT invoices.invoiceno, invoices.invoicedate, invoices.invoiceamount, customers.firstname, customers.lastname FROM Invoices JOIN Customers ON invoices.customerid = customers.id")
Results2.RemoveAllRows
Var grandTotal As Integer
Var totalIterations As Integer  = 10
For i As Integer = 1 To totalIterations
  Var start As Integer = System.Microseconds
  For Each row As databaserow In rs
    ListBox1.AddRow(rs.Column("InvoiceNo"), rs.Column("lastname"), rs.Column("firstname"), rs.Column("InvoiceDate"), rs.Column("InvoiceAmount"))
    ListBox1.RowTagAt(ListBox1.LastAddedRowIndex) = row
  Next
  Var stop As Integer = System.Microseconds
  Var total As Integer = stop - start
  grandTotal = grandTotal + total
  Results2.AddRow("Test " + i.ToString + ": " + total.ToString)
Next
Var avg As Integer = grandTotal / totalIterations
results2.AddRow("Average: " + avg.ToString)

I assumed the second test would take longer since it’s doing the extra step of assigning the row to the RowTag property. However, when I ran the test, something curious occurred. The second test, rather than taking more time to complete, took less. This made no sense to me. It’s doing more so it should take longer. It’s not logical that asking it to do more would result in the task taking less time. After examining my code, I could not find any issues with it.

I modified the code to run each test 10 times then compute the average of all 10 tests. Depending on the run, the average time for Test 2 was nearly always shorter. Occasionally the average for Test 1 would be shorter than Test 2 but rarely. In fact, on my M4-based MacBook Pro, Test 2’s average was, in most cases, anywhere from 5% to 25% faster than Test 1. Next I tested it on an M1-based MacBook Pro with similar results. Then I tested it on an x86-based PC running Windows 11. This time Test 2 was slightly slower than Test 1 as I had been expecting from the beginning. Last but not least, I tested on Windows 11 running via Parallels on my MacBook Pro, compiling for ARM-64. In this test, Test 2 was indeed faster. I tried running these tests by changing the order (Test 1 then Test 2 followed by Test 2 then Test 1) and by quitting between runs. None of that seemed to matter.

The difference appears to be ARM. It could be the compiler or the CPU. Our Director of Engineering, Travis Hill, suspects that perhaps something like the branch predictor in the CPU is hopping a tiny bit faster because of the extra assignment and thus can better predict the next operation with the For Each loop. That could be. The timing is in microseconds so the difference is so small that for my purposes, it doesn’t matter. However, that it’s faster to do more work in this case is fascinating and unexpected.

In any case, it’s interesting to see code behave in a way that is so counterintuitive. Asking the method to do more, at least on ARM-based machines, caused the method to take less time.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

However, functionality should take priority during the initial implementation. Focus on getting the app or feature working correctly and bug-free before considering optimization. Performance improvements are best handled in subsequent iterations. Remember, “Early optimization is the root of all evil.”

Here are five tips to consider when building or refining your Xojo applications.

1. Identify Bottlenecks with the Xojo Profiler

Before diving into specific optimizations, you need to determine where your app is spending the most time. Xojo’s built-in Profiler provides detailed information on method execution time, helping you isolate trouble spots.

• Enable the Profiler: In the Build Settings for your project, ensure “Profiling” is turned on. Then run your application in Debug mode.
• Analyze Results: After closing your app, review the profiler report to see which methods and lines of code took the longest time.
• Focus on High-Impact Areas: Tackle the biggest time sinks first—a small fix in a heavily accessed function can lead to noticeable performance gains.

Pro Tip: Limit changes to one area at a time, then re-profile. This approach helps confirm whether your optimizations actually improved performance. Read more about the Code Profiler feature: https://documentation.xojo.com/getting_started/debugging/code_profiler.html#getting-started-debugging-code-profiler-using-the-code-profiler

2. Use Efficient Data Structures and Algorithms

Choosing data structures wisely can dramatically impact speed, especially in data-intensive applications.

• Arrays vs. Dictionaries: For large datasets with frequent lookups, a Dictionary can deliver faster lookups compared to an array, especially when searching by a key.
• Avoid Repetitive Property Lookups: If you access the same class property or control value repeatedly inside a loop, store it in a local variable first. This minimizes overhead each iteration.
• Algorithmic Complexity: Review algorithms for large tasks. Nested loops that appear simple could become extremely slow for bigger data sets. If possible, replace them with more efficient sorting and searching methods.

Example: Instead of repeatedly using myArray.IndexOf(item) inside a loop, store the index in a variable once or switch to a Dictionary for faster lookups.

3. Offload Work to Threads

Making your application responsive often means running time-consuming tasks in the background.

• Why Threads Help: Xojo threads let you perform lengthy computations without freezing the main UI. This creates a better user experience and can let users continue working while the app processes data.
• Identify Good Candidates: Processing data, network transactions, or any tasks that take more than a fraction of a second can benefit from being threaded.

Pro Tip: If you only have a short delay (like reading a small file), threading may introduce complexity. Focus on threading tasks that truly benefit from parallel or asynchronous execution.

4. Manage File and Network I/O Efficiently

Disk access and network requests tend to be some of the biggest performance bottlenecks.

• Batch Operations: Rather than reading or writing data one line at a time in a loop, try batching reads/writes to minimize overhead.
• Cache Strategically: If your app frequently loads the same data (like configuration files), store it in memory for quick access.
• Asynchronous Calls: For tasks requiring large data transfers or multiple network requests, consider asynchronous approaches so the UI remains responsive.

Example: When generating reports, accumulate data in a buffer or in-memory structure, and then perform a single file write at the end, instead of dozens or hundreds of small writes.

5. Mind Your Loops and String Operations

Nested loops and repetitive string concatenations are particularly notorious performance killers.

• Minimize Nested Loops: Combine or break up loops that needlessly repeat the same work. For example, a single pass that filters and sorts data is typically faster than two separate loops.
• Efficient String Handling: Building long strings in a tight loop using the + operator can degrade performance because strings are immutable in many languages, and repeated concatenation can cause extra memory allocations.
• Use Add: If you’re concatenating parts of a string repeatedly, consider using an array combined with String.FromArray for more efficient handling.

Example: Instead of doing:

Var largeString As String
For i As Integer = 0 To 1000
  largeString = largeString + "line " + i.ToString
Next

…collect lines in a String array, then String.FromArray() them once. You’ll often see a significant speed boost in large-scale operations.

Conclusion

Optimizing your Xojo apps for performance doesn’t have to be an intimidating process. With the right tools (such as the Code Profiler) and a focus on data structures, threading, efficient I/O, and mindful loop/ string operations, you can significantly speed up your apps and keep the user experience smooth.

Remember to quantify the results by measuring before and after each change. By continuously profiling and fine-tuning your code, you’ll create compelling, efficient Xojo applications that delight your users.

Have fun optimizing and don’t forget to share your own performance tips or success stories in the Xojo community forums!

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Control Sets

There are cases where you have a bunch of controls with the same functionality. Imagine you are coding a calculator and you’ve just added the WebButtons for each digit. It would be repetitive and error prone to add the same code to Pressed events, on each button when the only thing that changes is the numeric value.

A set of controls can be grouped, so you can think about them like if you were using an array. You can add event handlers to the group itself. Events will be enhanced with an “index” parameter, to help you decide what to do, depending on the element.

Create Tabs and Embed Controls at Runtime in WebTabPanel and WebPagePanel

Same as with Control Sets, this is something that was already present in Desktop projects and we wanted to include it for Web. From now on, you will be able to create and remove tabs and pages in WebTabPanel and WebPagePanel controls, respectively. Controls can also be added and removed at runtime, or move controls between tabs or pages whenever you need.

This opens a new world of possibilities for your applications, where you can provide your end users a way to have multiple contexts open at the same time.

WebListBox: Configurable Header and Row Height, Border and Line Style

You will be able to configure the height of WebListBox headers and rows with the same API you are used to using in your Desktop projects. You won’t need to tweak them with CSS anymore.

HasBorder and GridLineStyle has also been added to Web projects, allowing you to remove the outside border, display only vertical lines between the columns… or just remove them.

WebDataSource Interface

Speaking of WebListBox improvements, you’ll find that the WebDataSource is easier to implement. You won’t need to implement SortedPrimaryKeys and UnsortedPrimaryKeys methods anymore.

There are only three methods required now:

• ColumnData: Where you will define the amount of columns, names, and configure if they are sortable
• RowCount: So the control can now the amount of space it will need
• RowData: This is where you return an array of rows

WebListBox lazy load rows, meaning that it will only ask your DataSource for the amount of rows being displayed on screen. It will only fetch more when needed.

WebListBox Improvements When Using a WebDataSource

Using a WebListBox with a DataSource makes it possible to display very large amounts of data. Until now, you were able to display thousands of rows very quickly. This release improves the way Xojo uses your DataSource, without having to change a line of code in your projects.

Scrolling through the data will display the rows much faster than before. Just for comparison, 2024r1.1 was able to display 1 million rows in about 6 seconds in my computer. The same project, using 2024r2, can display them in less than 100ms.

But is not just the speed that has been improved. Its memory footprint has been dramatically reduced as well. Displaying 1 million records in 2024r1.1 used about 1 GB of RAM, where 2024r2 will use just a few MB instead.

I can’t imagine a use case where you need to display millions of rows and scroll through them. But if you find one, you will be able to implement it with Xojo

WebButtons Can be Resized Now

In order to make it easier to migrate your Web 1 projects, you will be able to modify the height of your WebButtons. The web framework will also take care to reduce the font size if needed when the button is smaller.

Individual Indicator for Each Segment of WebSegmentedButton

There are situations where you want to mix different “indicators” (different colors) in a single WebSegmentedButton control. For example, pressing on one of the segments can be a destructive action, so you could use the Danger indicator. By default, segments will use the indicator you set in the Inspector panel, but you will be able now to individually override one of them.

Me.Indicator = WebUIControl.Indicators.Primary
Me.SegmentAt(1).Indicator = WebUIControl.Indicators.Danger
Me.SegmentAt(2).Indicator = WebUIControl.Indicators.Success

Having 4 segments, this will be the result of above example at runtime:

Outlined WebButton and WebSegmentedButton

Some GUIs could become overwhelming, when every button looks like a call to action. The new Outlined property, available in WebButton and WebSegmentedButton controls, can help with heavily loaded interfaces. Here is how it looks like:

Performance, Memory Leaks, Bug Fixes

Last, but not least, 2024r2 comes with great performance improvements. We’ve been improving the web server to handle even more requests per second. If you are using Xojo Web for exposing an API, it will be able to serve more requests in less time. For regular Xojo Web applications, it means it will be able to handle more events and reply to them faster.

Here is a comparison of the same project during the different releases of Xojo:

Latency has also been improved, Xojo is able already to reply in less than 2ms:

If you are still serving Web APIs with Web 1, this is a good opportunity to migrate:

That’s a Wrap!

As usual, I’d like to send a big thank you to everyone taking the time creating bug reports, feature requests and testing beta releases. This wouldn’t be possible without your support.

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Popovers

Similar to WebDialogs, popovers give you the opportunity to improve your apps’ UX. They are ephemeral screens where you can place text and controls.

Unlike the WebDialog, which is always centered and prevents the user to interact with other controls, Popovers can be placed on specific controls, where that information matters.

Think about them as enhanced “contextual menus” but, instead of just plain text menus, you can add anything you like. Have you ever dreamed of adding a WebMapViewer into some sort of contextual menu? Now you can!

The API is very simple. Create a container, add some controls and that’s it, really. You will just have to create a new instance of that container and show it as a Popover, specifying the control it should be pointing to.

Let’s say you have a container, called “MyTextFieldContainer”, and you want to display it below a WebLabel called “MyLabel”. Here is the code:

Var c As New MyTextFieldContainer
c.ShowPopover(MyLabel)

By default, it will be shown below the specified control, but if you want to show it in a different place, you can use the new DisplaySides enumeration. As easy as this:

Var c As New TextFieldContainer
c.ShowPopover(MyLabel, WebContainer.DisplaySides.Top)

As you can see, Web Projects’ Popovers are just container instances that you will show dynamically. That gives you the opportunity to raise events, add custom computed properties or implement the Observer interface. If you are already familiar with Containers, you already know how to use Popovers. Learn more about Popovers.

Displaying contextual menus programmatically

Sometimes Popovers could be overkill for the task. If you just want to display a menu with some textual items inside, a contextual menu might be enough.

Imagine you have a WebTextLabel where you want to display the contextual menu whenever the user Presses on it. In its Opening event you could define the ContextualMenu:

Var menu As New WebMenuItem
menu.AddMenuItem("Foo")
menu.AddMenuItem("Bar")
menu.AddMenuItem("Baz")

Me.ContextualMenu = menu

Implement the WebLabel.Pressed event and add this code:

Me.ContextualMenu.PopUp

As easy as that.

New RemoveControl method

WebViews controls, like WebPage and WebContainer, now supports removing controls. This gives you the missing piece to create GUIs programmatically, as AddControl was already supported .

This can be useful when you are presenting a form to your end user with an unknown amount of fields.

For example, your user is filling the profile and you want to support having multiple contact fields. Some users will want to add 1 phone, others 2, and others would prefer to be contacted just by email.

Adding and removing controls dynamically gives you the opportunity to build this kind of features. Instead of adding a fixed amount of contact methods, you can adapt your app to what your user really needs.

Performance and memory usage improvements

We’re landing at my favorite part, improvements that nobody will see… unless you want to share your server monitoring stats, which is cool.

2024r1 comes with less Disk I/O usage. In my own benchmarks, Xojo Web is now able to serve about 1200 requests per second via the WebApplication.HandleURL event. That’s around a nice 20% more, compared to the previous version.

Also, thanks to Jeremie Leroy (one of our Xojo MVPs) and Bruno Fréchette, we’ve managed to identify and fix some memory leaks. In 2024r1, your web application will be doing a better job at cleaning up after processing requests.

Bug fixes

The list of fixes is big, you can inspect the whole list in the 2024r1 Release Notes page.

Web fixes by category:

• Compiler: 1
• IDE: 7
• Framework: 40

18 extra regressions were reported and fixed during the beta period. A huge thank you to everyone taking the time to test our releases and reporting issues before the final release becomes available.

Conclusion

We hope you are as excited as we are for this release. I’m personally looking forward to see what you’re building, please remember to mention us on your favorite social network so we all can see what you’re working on.

In the meantime, we are already working hard preparing our next release, 2024r2. Spoilers: You will love it!

Happy coding!

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

Faster HandleURL Responses

With Xojo Web you can create APIs backing your Mobile or Desktop applications. Just by updating to Xojo 2023r4, your web services will get the benefit of much faster responses and the ability to handle many more requests per second.

Just to compare between different Xojo versions, we’ve created some benchmarks using Xojo Web 1 (with Xojo 2019r3.2) and some Xojo Web 2 releases, 2023r3.1 and the latest one, 2023r4.

Here are the results, returning plain text:

And the same test, but this time returning a string generated by JSONItem:

Xojo 2023r4 is capable of serving around 20x more requests per second compared to Web 1, and around 4x compared to Xojo 2023r3.1. And thanks to the reduced latency time, your API will return the contents much faster.

Faster Transfer Rates in Windows and Linux

While working on performance, we’ve found that applications deployed on Windows and Linux were serving large files much slower than those deployed on macOS servers.

William improved the low level code for sockets on those targets, allowing the server to transfer large files at a much faster speed. During my tests, I’ve seen 10x faster transfer rates.

But this doesn’t affect only our Web target! If you are using a ServerSocket with TCPSocket classes, your Console and Desktop applications will also benefit from these improved transfer rates.

Static Assets Cache Control

In this release, we’ve also improved how the framework interacts with the browser. When your user visits your web application for the first time, it will store all of the required JavaScript and CSS files.

This was already happening in previous releases but with a subtle difference. From now on, the browser won’t even need to check with the server if the file has changed since the last visit. This translates to faster load times for your users and less server load for you since the server won’t need to handle all those requests anymore.

Improved Compile Time

In this release, Xojo Web will compile your projects a few seconds faster. The first time you compile your project, it will cache the result of some processes that are only changing between Xojo releases.

Here is a comparison between 2023r3.1 and 2023r4, both are running a debug session of a blank project:

That’s around 3-4 seconds faster every time a project compiles.

Events Improvements

Some web controls were sending information from the browser to the server more frequently than needed. For example, a WebContainer.Scrolled event was being sent for every scrolled pixel, causing unnecessary server load.

We’ve been reviewing these controls and have made some improvements:

• WebCombobox
• WebContainer
• WebSearchField
• WebTextArea
• WebTextField
• WebUploader

All of them will continue communicating their state updates, but the framework will focus on delivering the latest value available.

For example, in a WebSearchField, if the user writes “hello”, the framework will send the first key press (“h”) as soon as it happens. The next event it will send will depend on how fast the user types, so it can be either “hel” or maybe directly “hello”. What is guaranteed is the TextChanged event will be fired for the final value (“hello” in this example).

New Experimental Option

WebSession has a new experimental option available, disabled by default. “Send Events in Batches”:

Turning it on will make our JavaScript framework group different event notifications in a single request. Projects that contain complex layouts that show and hide several controls at once may benefit from snappier GUIs.

As a side effect, it will also ensure the events arrive to the server in the correct order. Think about a login screen where the user has an email field, a password and a “Login” button with the Default setting turned on (to allow the user to trigger the Pressed event by pressing the Enter key). When sending the events in different requests, because of network latencies, the WebButton.Pressed event could arrive at the server before the last WebTextField.TextChanged.

We would love to hear your experiences when turning on this experimental option. If you find an issue, please report it.

Wrapping Up

As always, while Xojo 2023r4 comes with a lot of performance improvements, it also comes with bug fixes and feature requests. I want to again thank everyone who took the time to create new Bug reports and Feature Requests, and tested the pre-releases.

We’re looking forward to see what you build with it!

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube