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.
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.
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.
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).
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
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).
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.
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)ā¦
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.
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.
.
