Xojo uses CPU without doing anything

I do not know if this was the case in previous versions but Xojo 2023 R1.1 uses in idle (read: no project loaded, project open dialog/window not visible, between 2% to 18% CPU.
it just sits there using CPU cycles for doing nothing?

I noticed this because the battery % was draining faster than usual. Opening the Activity Monitor revealed Xojo was using +15% CPU at that time (with no project loaded). I closed Xojo and relaunched Xojo, and it still uses between 2% (sometimes up to 18%) CPU without doing anything.
Things I tried:

  • rebooted the system.
  • Uninstalled and reinstalled Xojo.

It keeps using CPU idle (taken a peek what it is using now while I use Safari … 2.5% CPU). Even just launching it and doing nothing.

What’s going on?

BTW running on MBP 16 M1 Pro - macOS 13.3.1

Some more info:

Loading a project and closing that project, every single time builds up the CPU load for Xojo.
For example, after loading and closing a project 5 times, Xojo was using 14% without doing anything (read: no project loaded, no ‘choose project’ dialog, nothing… ).

I checked some older Xojo versions too but the problem is more severe with 2023R1.1 but also happens with previous versions.

So basically this means it is no good idea to keep Xojo running in the background when you are not using it.

Anyhow, this should be looked at. An app that is not supposes to do anything (in Xojo case, no project loaded) it should use zero CPU load.

2023r1.1 on my 13" M1 with Ventura 13.3.1. After a morning with multiple projects (in sequence, not open at once), it’s not as bad here as Xojo is bouncing around between 1.2-1.4%. But the RAM usage has climbed beyond three gigs.

Try loading the project, closing it and doing this 4 or 5 times. And then take a peek at the CPU load.

As said, it should be zero CPU load when no project is loaded for sure.

Well, it seems to me (I don’t know) that even an idle application is running an event loop waiting for the user to do “something”. But what you’re reporting is definitely excessive. :slight_smile:

Look at Activity Monitor, and you’ll see a lot of apps using 0% of CPU, including UI ones. I guess the event loop doesn’t count :man_shrugging:.

RAM and CPU being overused in Xojo is not new.


Yes, I’ve noticed the RAM use, particularly the growth as Xojo remains open, for some time.

Just tried it here.

The CPU usage does go up slightly but nothing compared to what you are experiencing.

According to XCode Instruments, about 20% of the CPU usage is Xojo polling a socket and running a timer associated with the code editor canvas (which is weird as I don’t have a project open).

1 Like

I see this:

ezgif.com-video-to-gif (14)

First time it goes black is that I clicked in Xojo2023r1.1, the CPU goes up to 9.1 after that, the second black is Notepad full screen so no part of Xojo is visible, the CPU goes down to 0.0

MacMini, Intel, Ventura 13.3.1

Some more info:

Xojo2019r1.1 does not have this CPU use when no project is loaded. It’s always at 0% CPU load.
So there is definitely something changed and doing something in the background with the newer Xojo versions.

Now what’s even more worrying, the CPU load is even there when I close my MBP. My battery drained from 98% to 93% in about 2 hours when I did not used my MBP (Xojo was the only app still running). When I quit Xojo before closing my MBP, the battery does not drained anything after 7 hours (woke up this morning and checked).

Not good.

A bug report is in order :wink:

I wanted to have a look at how Xojo behaves yesterday. After a couple of debug runs the CPU usage was at 30%. After quitting and restarting it switched between 1 and 14 %. Xojo ALWAYS has had memory problems.

If you do a bug report don’t forget to add a sample from Activity Viewer.

It’s quite possible, that Xojo starts a timer for some kind of animation and never stops it.

or uses a timer in code, uses add handler and creates the problem, that addressOf retains a reference to the window, while the timer has a reference to the delegate and the window a reference to the timer, thus creating the loop which prevents this to be destructed.

If someone can look on the code of the IDE, please check usage of AddressOf vs. WeakAddressOf and prefer the weak variant, so the loop above doesn’t happen.

1 Like

Using memory and CPU load are two different things.
I’m more concerned about the CPU load (in idle)

So what? With the Activity Viewer or Instruments you can see what Xojo is doing.

The IDE is busy polling Xojo servers about licence numbers… and change, eventually, the used machine/os if it is different from the ones already used, so it can tell you "this license is in use” (or other messages)… :innocent:

1 Like

Christian, pure speculation like this really is not helpful. If you have proof that the IDE is doing something like this, that’s one thing. But to say “it’s quite possible that” and then go off on a tangent as if you actually know isn’t fair.

I can tell you for a fact that Norman and I removed all animation code from the Xojo IDE in 2013/2014 because of how slow it made the IDE with no obvious benefits beyond making it “pretty”.

This is not to say that the IDE doesn’t have timers to run processes in the background. For instance, there’s a timer to flash the cursor in the code editor (since it’s just a canvas). I’d be curious to know if the people who are seeing the cpu hit have a code editor open or a layout editor. It’s also possible that there’s a hit for each additional open tab.

Just for clarity, just going through and replacing AddressOf with WeakAddressOf is not a sound technique in all cases. I don’t want anyone to think that it is because the Weak version has its own set of problems.

1 Like

Please read what had been posted. The CPU load is when NO PROJECT is loaded. So why asking if there is a code editor or layout editor open?

I ran a quick test for Christophe on my Mac and profiled Xojo using XCode Instruments.

CPU usage was because of socket polling and because a timer, which from its name seemed to be related to the code editor. There was no projects or windows open at the time so a timer related to the code editor seems weird.

I would report it, but that would just be a waste of my time.