+1. My Windows 10 computers and a couple of Linux computers run 24/7 and reboot monthly when Microsoft updates require it. I don’t notice any performance degradation on these computers.
Some computers where I try stuff (install and remove trial software, change configurations and redo, etc.) need rebooting and even re-installing the OS from time to time. That is entirely related to what I do on these machines, not to a flaw of the OS.
[quote=475201:@Beatrix Willius]If you don’t invest time to find out what is causing the slow down the problems likely won’t get fixed. And the problems with the debugger haven’t been mentioned before.
Xojo doesn’t have time to port back fixes.[/quote]
Sorry, Trixi, but that is just not a reasonable perspective. Xojo isn’t a free, open source product. We pay to be able to use it and we are justified in expecting it to function properly. It’s not the user’s job to determine why a product does not work as expected - even more so in a development environment. As users, we don’t have access to the product’s source code, so we only see what we see. What happens between when we type CMD-B and the app launches? We have no idea. How can we do more than report what we see.
Imagine if you were required by your car manufacturer to determine the exact cause of the noise you hear when driving before they would fix your car. Or that your doctor require that YOU completely diagnose your problem before they will determine what your treatment should be.
Granted, some of us go outside the norm and run debuggers on top of debuggers (strace, kdump, Instruments, etc.), but that’s not our job as “users” and “customers”. At worst, we should be asked by the product company to allow remote access to our systems to try to debug using their source code (and the Xojo Remote debugger would allow that easily for them). I’ve made that offer many, many times in my feedback reports, but I’ve never need taken up on the offer.
It also worries me that so many reports in the feedback system are still marked as “Needs Review”. While these may have been touched by someone within Xojo’s team in some manner, all that we see on the outside is that our submission has gone unnoticed.
As for Xojo not having the time to back-port, that’s what I meant with my stating that I “wished” that they had an LTS model and the staff to do that.
We are developers. Yes, we pay for Xojo. But we are also expected to make reproducible bug reports.
As for your comparison: you will stay much healthier if you come to the doctor with the diagnosis.
[quote=475260:@Beatrix Willius]
As for your comparison: you will stay much healthier if you come to the doctor with the diagnosis.[/quote]
A clear description of symptoms for sure.
But a diagnosis ?
Most doctors would probably ignore your diagnosis and do their own tests since you’re not a medical expert.
All that said 15 years of Rapid Release model and persistent complaints about quality would make you think that something else would be tried to improve that.
Somehow Xojo needs to get out of the “perpetual beta” state.
Actually I think hers is the only reasonable perspective. If there was some for the developers obvious or easy to spot bug they would have fixed it. In this case, some customers are experiencing an unacceptable slowdown while others (probably most) are not. I guess that the Xojo developers dont experience the slowdown either and as long as the issue cannot be reproduced there is little chance of progress in finding the bug. It boils down to: Do you want the bug to be squashed or not? If you do then you should do your best to document the conditions under which it reveals itself.
If the same subject is still being discussed then I think you are beating a dead horse …
I guess you can keep adding to it, but if the behavior is verified why would someone need to keep banging their head against the wall to produce more evidence … that would be akin to insanity (and as much as sw devs may be prone to that, it doesn’t mean it is rational).
on macOS make sure you have activity monitor open and can quickly start a sample of Xojo when this occurs
those can be very instructive
If you search through the feedback reports on these issues, you’ll finds traces, memory reports, videos, and even invitations to the Xojo team to use the remote debugger on my systems where the issue is reproducible every hour of every day. I’d say that we’ve done what we can as outsiders.
Remotely debugging the IDE is difficult
My fear is not being able to buy a new 2019 Mac Pro computer, 256 gbs ram, 24 cores and that they can no longer work in a flirting way with Xojo, knowing that in Flutter the changes are seen in real time in the emulator? that’s what I expect from Xojo to be able to do things fast
OK, folks, if you take a look at <https://xojo.com/issue/56900>, Travis has asked that we start filing independent, issue-specific, reports on the slowness problems:
[quote]We’re going to refocus speed cases like this to very specific issues that can be independently Verified and flagged as Fixed. There are various unrelated things mentioned together on this case, so this particular case will be refocused as this specific speed issue brought up early in the case:
“Selecting and deselecting container controls in the navigator with many controls (see attached slow_clicks_api1 example project) in current versions of Xojo appears slower than 2019r1.1.”
Please file or favorite independent cases (with an example project if possible!) if you have a scenario that demonstrates slower autocomplete, code editor, dragging, slowdown-over-time or issues that are not the above. We certainly want to address these where possible, but too-broad cases aren’t great for tracking what often turn out to be wholly separate items. Thanks![/quote]
Please help out with this. They’re going to dig in to these issues, but they need to be able to track them appropriately.
@Victor Manuel Osornio : if you manage to slow down a new MacPro then you know that you really have a problem.
This took far to long… 
Have a look at this trace… You can see the spikes where I was scrolling the navigator (this is the slowest part of the IDE for me)
Compare this to 2019r1.1
Now, turn off dark mode… (2019r2+)
See the difference? “AppearanceAwareCanvas.Event_Paint” in 2019r2+, also notice the heavy use of “GetImageForIDE” in dark mode which appears to be accessing the file system for each draw call? Could this be the reason for the 3-5 seconds between scroll wheel to actual movement of the navigator? Should I make this its own bug report? I wonder why it is not slow for some people (maybe not using dark mode?)
As Xojo splits up each method into its own file and properties must be selected to edit, we need to bounce around in the navigator a lot, performance in this area is key. I can work with slow bootup time but the navigator is critical to getting work accomplished.
I appreciate all the devs working so hard to squash this bug!
Light/Dark Mode made nearly no diff here (MBPR 2018 16GB/128GB/Vega 64 eGPU & internal Radeon 5xx).
On Linux, it’s exclusively a memory leak issue. On Windows, I suspect the same, but on macOS, I also see the light more / dark mode sluggishness as well as a few memory problems relating to multiple debugger or build runs.
It doesn’t actually. All of our image loading routines cache the images in memory after the first time they’re pulled unless you switch between light and dark mode, in which case the cache is cleared and the images are loaded on demand again.
Seems to be taking a lot longer in dark mode, is it possible that the cache is not working for some reason?
The first trace in dark mode show picture.open being called a bunch
The second doesnt
Would seem to suggest something about caching isnt working as expected
PictureOpen being called a lot
Picture open not being called
Ha! There are obvious bugs right on the main screen of the IDE that have remained unfixed since the Xojo IDE replaced RealStudio.