For any of you running the IDE on macOS Big Sur, if you’re using Time Machine and are seeing slowness in the code editor, please use Disk Utility to do a First Aid check on your Time Machine drive(s). I have no idea why these things are connected, but it made a huge difference on my system here.
Edit: The affected machine has an Intel processor.
Thanks for sharing.
I have been using Disk Utility on my main drive only (due to glacial slowness at times), not the Time Machine drive, so thanks for the suggestion!
Agreed. It took something like 14 hrs to scan my 8TB drive.
Has anyone at Xojo actually looked into why this causes a drop in performance other than basic troubleshooting of removing software/hardware until a problem is found? I can’t see a feedback ticket for this.
If not then Xojo should be making this a priority to find out why, not only for the known issue of using TimeMachine but for the underling cause which could be effecting other backup technologies unbeknown to Xojo and also to find out if its a framework issue that could be affecting other customers apps or if its just an IDE issue.
We have actually. We identify a few candidates each cycle, focus on those and we have made some improvements.
Not every ticket is visible to users.
The biggest issue is reproduction. Even with all of the different machines we have access to, we have not seen anything as severe as what is described here. For instance, I have a 2011 Mac Mini, a 2012 Mac Pro, a 2015 MacBook Pro and a 2019 MacBook Pro at my location. We also share machines remotely between locations if necessary.
While I’ve not experienced performance issues on customers machines (there was one in Catalina, but I was able to reproduce it and file a bug report with Apple).
I have experienced Core Image being absolutely broken on customers machines, which cannot be reproduced with a plethora of machines. Same Mac, same version of the OS, yet the customers Mac produces a black image instead of a proper image. I even wrote code to validate that what the customer says is true, sadly. Customer was not willing to attempt a clean install to run my software, instead got a refund and went with a competing app that doesn’t use Apple’s imaging API.
I am hoping that a managerial change in Apple will result in someone taking charge who actually cares about these things and puts more attention on creating the products, rather than trying to create a new revenue stream.
That is great news, I assume you’ve found this out since you mentioned above that you had no idea why they were linked?
Maybe if the ticket were public, more eyes could be cast upon it and further assistance could be provided instead of everyone working separately in the dark not knowing what has/hasn’t been checked?
Actually we’ve put some time towards speed issues every cycle for the last two years at least. We don’t always make spectacular progress, that’s all.
Like Sam, it’s tough to know if we’re making a difference on user machines though when we can’t reproduce the issue here.
There’s nothing that an end user can do with these internal tickets and they usually contain mostly private info anyway, so you’d see a title and no content. Just like a disease, the thing we need is to figure out what it is that’s common among the systems where these problems exist.
For instance, when I buy a new machine I typically get the best video card I can afford because it has a huge impact on overall performance of the things I care about, so 3 out of 4 have a Radeon 560 or 580. Does that matter? We don’t know because we typically don’t get that kind of info in a bug report.
We also know that users who use a ton of plugins run into issues. I’m not saying that plugins are bad, just that they can contribute to the overall speed of the product.
I’m confused now, I was talking about the specific issue regarding Time Machine which you can reproduce? You said that it made a difference to turn it off?
One would assume that profiling the IDE while a reduction in performance would indicate where the performance hit is affecting the IDE/framework? Do we need to do this and provide data for Xojo or has this already been done and the problem identified? Without seeing the ticket we don’t know if the rabbit hole is worth jumping down.
Then perhaps the information could be sanitised and made public to aid in the resolution of these types of problems?
Perhaps a data collection tool is required for bugs so you can garner as much information as is practically viable?
But I’m getting side tracked, this was meant to be about the Time Machine issue.
No, I said it made a difference to run First Aid on the drive.
We do that from time to time, most recently about a month ago. The solution isn’t always straightforward though. For instance, one thing that causes speed issues is exhaustive recursive searches of the frameworks and user projects. And yes before you state the obvious, Frameworks are cached because they don’t change, but user code is more complex because it does change. That said, a single search for the IDE which searches all of the desktop frameworks and the entire IDE projects takes roughly 0.03 milliseconds on my machine. The problem becomes that the IDE has to do these lookups a lot, with the most time being in project loading and autocomplete. A search of the roughly 100,000 items suddenly becomes 3 seconds, but 0.03ms is darn near instantaneous and squeezing more time out of that routine doesn’t get us much.
The reality is that without giving you access to the source code (which we’re not going to do) and 6-12 months to get a basic understanding of how everything works together (the minimum time an engineer has to work here before they can check things into the IDE Trunk. I’ve been the primary on the IDE since March 2019 and just passed my 10th anniversary and am still learning things every day) , we can’t even start having a conversation where you would be able to offer meaningful suggestions as to what we should look at next. I’m not saying this to be mean, it’s just the way it is.
Just a suggestion: I do wonder if you could add an option that would track where you believe the slowdown is and collect information that you think is related to the slowdown?
This way when a customer reports IDE slowdowns, they go activate this tracking mode and it starts sampling, and collecting data to which they can then send to you.
And I realize that even adding in a context switch which can be used to activate more tracking, will affect the performance of the routine.
We are developers and not little children. We want you to find the slowdowns. We can do testing if you give us some information.
The only thing I can reproduce is that Xojo bares functions when TimeMachine decides to copy lots of GB.
Ah I see, the process of first aiding the disk causes the issue to go away which is what you’ve done, so are you able to replicate that now or has your only chance to get to the bottom of that issue now gone?
If you’re now unable to replicate that issue wouldn’t it be more prudent to ask people who are experiencing IDE slowness to try turning off or disconnecting Time Machine to find out if its the cause of their issue instead of telling people how to permanently fix the issue and thus render their system useless in aiding any future investigation into the issue?
With all due respect Greg, if I had listened to similar lines from Xojo regarding the windows framework flicker issue then I highly suspect that would still be an issue to this day.
I’ve been asking for this for a long time in feedback but nothing has come of it, the only way to ensure that this feature didn’t impact other users would be to provide a separate debug/logging build that we can run to collect data in situations such as this. Alas, this has not happened yet.
Likewise, but we’re not talking about a framework issue that shows up in user projects this time either that you can give us reproducible example projects either.
Well… on my machine (and the others I checked) there was a kernel process using more than half of the available CPU all the time. That’s not an IDE issue, so no, we didn’t go that route.
Julian, while I appreciate your zeal and your apparently unlimited time to debug stuff like this, my experience is that most users just want a quick fix for stuff like this and don’t want to help build a solution for everyone because “that’s not their job, it’s ours.” I understand that’s not all users and even I get pedantic sometimes over fixing a particular bug, sometimes to a fault, but it certainly is a large portion of the users I interact with.
I’ve been asking for this for a long time in feedback but nothing has come of it, the only way to ensure that this feature didn’t impact other users would be to provide a separate debug/logging build that we can run to collect data in situations such as this. Alas, this has not happened yet.
We have built IDEs over the years with this sort of logging for individuals, but I can tell you that they aren’t productive to work in for very long if your machine is running slow… to the point where most users would give up after a minute or so. Since many reports begin with “the Xojo IDE has been running continuously for 24+ hours on my machine…” I seriously doubt we’re going to get there. I can’t even imagine leaving the IDE running overnight though, it’s just not my style.
Anyway, my current direction of inquiry is to figure out if there is a common system hardware configuration or software package installed on the machines.