I’ve been building my app with 2023r4 for a while now, as I typically only update Xojo versions when I do a major version update of my app. Well it’s been a while, I have no major version on the horizon, and I wanted to make use of some newer features. Ran some tests, looked fine, so I went for it.
Now that it’s in the wild, we’re realizing the app is now super slow. A task that might have taken a minute, maybe two, is taking closer to an hour. The effect is more noticeable on Windows, but it’s definitely still there on both platforms.
So between 2023r4 and 2025r2, something changed. Nothing has jumped out at me in the release notes. My suspicion is it’s SQLite-related, as the processes that are slower make heavy database usage.
I’m already using aggressive compile. I noticed my build size got smaller after the Xojo update, which surprised me. I had thought that maybe normal or moderation compile was active instead, but that doesn’t appear to be the case.
I’m going to run some profiler tests in the morning. But this is a major performance drop, so I’m just wondering if anybody has any ideas about what this change might be.
you could make a simulation of this job and test with other versions of xojo after 2023 and see when it jumps to a hour or at least took longer.
to track down waste of time i made a simple stop watch class and put it at methods to mesure a job from start to end
with sub methods/tasks. could be more informative than the build in profiler.
My suspicion is it’s SQLite-related
have you bundled many querys in a single transaction or without use of transaction?
Yes. Every time I want to write to a database of any flavor, I always use a transaction. In this case, all the work is inside a transaction with smaller chunks using save points.
You certainly seem to have covered all the bases and checked the probable causes. Moving to less likely then. I wonder whether choosing a different compilation optimisation level might make a difference. Up or down from the usual.
Preliminary findings. Tested the same code in 2023r4 and 2025r2.1 using the profiler to give me hints. One of my key methods is taking considerably longer, taking an average 0.5ms in 2023r4 and 3.3ms in 2025r2.1. However, none of the methods called from that method are taking any longer, even by a 10th of a millisecond. That tells me the issue in that method and no deeper. Thanks to this being and open source project, if you’d like to follow along at home, the method in question is this: Beacon/Project/Modules/Game Support/Ark/DataSource.xojo_code at f3d2be1562996882745fe2fa3eb7b0b5a8764446 · thommcgrath/Beacon · GitHub
This method gets called a lot because there are a LOT of items in the game. Caching definitely helps, but at the end of the day, thousands of calls to this are simply unavoidable. So that increase in time is brutal, taking one of my more intense processes from 53 seconds to 21 minutes.
Best I can figure is it’s the Results.Column call to blame. I tried switching to using a for loop, but it made no difference.
I’ll need to create a simple sample project to confirm. However my gut tells me I’m wrong and there’s something else going on. I’ve benchmarked individual calls to the method and they are considerably faster in 2025r2.1, so I’m not quite so certain. Still poking around.
Have you tried to comment the method out to make sure that this is the correct method? There were some odd slowdowns in the past. But accessing a column in a rowset/recordset should have been noticed earlier.
Well, I’m giving up. I’ve fallen back to 2023r4, and I guess I won’t be renewing anymore, since I can’t effectively make use of new versions.
I’ve commented out as much as possibly can, removed the Dictionary.HasKey, and pre-sized the array to the number of results. The extra time spent is just… lost. I can’t make it do any less work, yet it’s still slow in 2025r2.1.
I haven’t had any luck reproducing it in a test project either. So I’m cornered.