Why is XOJO so slow?

I have noticed a general slowdown over time as Realbasic ballooned into RealStudio and then into Xojo. On the other hand computers have become more powerful.

The most responsive Mac OS I ever saw was System 7.x.x on a Macintosh SE, but I don’t want to go back to that. That was also the only Mac computer I saw with infected Windows generated file that was caught by an early antivirus program. I had the good luck of stopping a garage sale for a guy that worked for a Apple dealer back in the 1970s and 1980s in the state capitol. His basement was crammed full of shelving units with items he had saved from the dealership. Consider yourself lucky you are not working on a Macintosh Portable :0)

I tend to take good care on my Macs thus I still have a G4 350 MHz and a G4 dual 867 MHz running legacy equipment here. I have Realbasic & RealStudio installed on these and noticed various degrees of slowdown depending on what you are doing.

Although I have a newer Mac Pro I don’t attempt to do any serious work on it due to the limitations of laptops. They can only cram so much in the given space, which limits what you can do. My main workhorse is a Mac Pro Mid 2010 2.8MHz Quad-Core with a ATO Radeon HD 5770 1024 MB running a NEC PA241W and PA242W. It has four internal drives and additional backup drives via a external dock setup.

Drive 1 is for the OS and any applications only.

Drive 2 is another copy of the OS.

Drive 3 & 4 are for user generated content. Putting such content on the OS drive would gradually fill it up and slow it down. I like using WB Caviar Black 1TB drives.

I also do not store anything on the desktop other than a couple of Applescripts. A lot of items on the desktop can slow down the OS. You can test this by creating a app that uses a loop to write new files to your desktop. After awhile you will get a beachball for just nudging your mouse.

I don’t have any problems using Xojo while Photoshop, Illustrator and others apps are running.

No I don’t. As I mentioned I’m a pretty novice user.

Not that I’m aware of. All the files I use with my program (which are just .csv files) are located on my SSD. And to clarify, when the program is running, everything runs perfectly smoothly. It’s only while using the IDE that things are slow. And what I don’t understand is that I’m not making complicated programs. We’re talking highschool programming level stuff here. I’ve built a program that reads a .csv file and puts it into a listbox and then the user (myself as I’m the only user) can then edit that listbox and add, edit, or delete entries. That’s all the program does.

Also, earlier someone asked which plugins I was using and I said none. I was mistaken. I have the following plugins installed:

MySQLCommunityPlugin
ODBCPlugin
OraclePlugin
PostgreSQLPlugin
MSSQLServerPlugin

I don’t use these plugins and I have no idea what they are or what they do. (As I said, I’m a novice).

Thanks again to everyone trying to help!

not sure quite what your issue might be… my current project is now weighing in at about 35,000 lines, with dozens of windows, classes and modules

[quote=467604:@Dave S]I have Xojo projects that animate hundreds of objects (being dragged by the user) and it runs very fast… even at acceptable levels on an older 2010 MBP.

You aren’t connected to a remote server or cloud perhaps?[/quote]

The actual build applications are in no way slow, the IDE is slow.
But it wasn’t that slow before…

[quote=467621:@Derk Jochems]The actual build applications are in no way slow, the IDE is slow.
But it wasn’t that slow before…[/quote]
my point is the IDE for me has no issues with that size project

I see some major slowness in the latest releases…progressively worse after 2017.

Clicking from a folder to a window and back to the folder(after the window editor appears) in the IDE… the window has about 280 controls (labels, textfields, canvases on several pagepanels) takes about:

2017r3: 4 seconds
2018r4: 15 seconds
2019r1.1: 15 seconds
2019r2.1: 24 seconds
2019r3: 24 seconds

Try opening your project in 2017r3 and see if it’s more responsive.

I agree. I use 2017R3 for most of my work. It was the best and remains the best development IDE for me. Then, I open the app in 2018R4 to add dark mode capability. But when dark mode is not needed, I also compile in 2017R3 which has the best 64 bit speed, especially for math intensive calculations.

Xojoscript math performance was broken in 2018R2 and continues to be broken for any context based math operations. It is a known issue:

<https://xojo.com/issue/52780>

Another reason to stick with 2017R3 whenever possible.

Also, on MacOS TimeMachine can drag performance down in my experience and Console.app is a Xojo killer (no idea why but I’ve forgotten Console was open and Xojo crawls).

wow… I expericne NONE of that… guess I’m just lucky :slight_smile:

[quote=467578:@Greg O’Lone]
What we do know:

  • Apple’s insistence on drawing controls in recent years with translucency contributes greatly to this problem. Dark mode only exacerbates the problem.
  • Having an SSD drive helps a lot. Make sure you have adequate free space available ( I like to have a minimum of 100GB free at any given time)
  • Having more than just the Intel integrated graphics card is also important.
  • If your machine has two video cards (integrated intel + Radeon xxx) see if turning off the automatic switching helps (in the energy settings).

Remember, the Xojo IDE gets its control drawings directly from the OS itself, so graphics performance is very important.[/quote]

Greg, these are all good points but it doesn’t explain why the performance of the Xojo IDE is getting worse with just about every release. No other application we use suffers from such a dramatic change in performance between versions. We are running macOS 10.11 so Dark Mode cannot be to blame.
2019r2 is now so slow that it is unusable. Because of this we decided not to renew our licenses. From the tests we performed (and reported in Feedback), the 2019r2 code editor was 3x slower than the 2019r1.1 editor which was also 3x slower than the 2017r3 code editor. I must admit I didn’t spend enough time in other areas of the IDE to notice if they were also affected due to the API v2 omnishambles but I would be surprised if they weren’t also slower.

[quote=467633:@Dave S]wow… I expericne NONE of that… guess I’m just lucky :slight_smile:

[/quote]

It takes a while for Console.app to start affecting Xojo, but after 24 hours Xojo is completely unusable for me.

Fire the Disk Utils application and check your Hard Disk and Partitions.

Boot / Shutdown five or more times in a Row without launching any application and wait until the computer “stabilize” (stop doing things) before shut down, then press the Startup key (do not use Reboot button).

Try the safe boot two or three timesif the above is not enough.

When you fire Xojo, only load your project and do not save the test changes (or better, create a brand new one).

Use Save As with your Project, quit Xojo, Poser Off / Power On / Launch Xojo / Load the Save(d) As… version.

Beside that…

[quote=467634:@Kevin Gale]Greg, these are all good points but it doesn’t explain why the performance of the Xojo IDE is getting worse with just about every release. No other application we use suffers from such a dramatic change in performance between versions. We are running macOS 10.11 so Dark Mode cannot be to blame.
2019r2 is now so slow that it is unusable. Because of this we decided not to renew our licenses. From the tests we performed (and reported in Feedback), the 2019r2 code editor was 3x slower than the 2019r1.1 editor which was also 3x slower than the 2017r3 code editor. I must admit I didn’t spend enough time in other areas of the IDE to notice if they were also affected due to the API v2 omnishambles but I would be surprised if they weren’t also slower.[/quote]
This all still comes back to the fact that if we can’t see problem, we can’t fix it. If the code editor was 3x slower in 2019r2 than in 2019r1 for us, you can bet that it would have been resolved because most of us work in the IDE all day long. That said, we don’t routinely work in 10.11 either. I’ve got both a 10.14 and 10.15 physical machines which I work on plus parallels VMs of 10.10 through 10.15 to test on.

Hi Greg,

Is there a way in which I can take a video and show you what I mean? Is it a matter of downloading a screen capture program and uploading it to youTube? Like it’s mindblowing. Just trying to scroll through my objects is painful.

Hi again Greg,

Here’s a video I took showing how much the IDE lags with just trying to scroll around the IDE:

https://youtu.be/ykAisRy40JM

Can you confirm if this is normal or am I actually having an issue here.

[quote=467650:@Troy Baxter]Hi again Greg,

Here’s a video I took showing how much the IDE lags with just trying to scroll around the IDE:

https://youtu.be/ykAisRy40JM

Can you confirm if this is normal or am I actually having an issue here.[/quote]
You’re having an issue. What is strange is that I got similar performance from 2019R2 but I’m fine with R3. I pretty much skipped R2 and stuck with R1.1 until R3 was available. Try clearing your caches: Preferences > Building > Clear Caches

Hi Gavin,

Thanks for the tip. I tried it but no effect. Still very slow.

[quote=467634:@Kevin Gale]
2019r2 is now so slow that it is unusable. Because of this we decided not to renew our licenses. From the tests we performed (and reported in Feedback), the 2019r2 code editor was 3x slower than the 2019r1.1 editor which was also 3x slower than the 2017r3 code editor. I must admit I didn’t spend enough time in other areas of the IDE to notice if they were also affected due to the API v2 omnishambles but I would be surprised if they weren’t also slower.[/quote]

Strange, I see none of this. Since October I’ve gone 2019r1.1 -> 2019r2 -> 2019r2.1 -> 2019r3. No noticeable change in IDE responsiveness.

[quote=467650:@Troy Baxter]Hi again Greg,

Here’s a video I took showing how much the IDE lags with just trying to scroll around the IDE:

https://youtu.be/ykAisRy40JM

Can you confirm if this is normal or am I actually having an issue here.[/quote]
Interesting. What you’ve got there is a refresh issue. That is, if the refreshes were happening at the normal rate, it wouldn’t be faster, but it would be smoother.

Do you use a lot of control arrays?

I think I’ve provided all of the data I can in the Feedback case I logged during the 2019r2 beta. If there is a way you can collect performance data (maybe via a special build) then I’m more than willing to do that.