Been said before, I'll say it again — IDE is sooo slow

I’m running Xojo 2018R3. First let me say that dark mode is beautiful, and the interface is getting better and better. You guys are doing a great job there. Incremental compiling is also huge improvement. THANK YOU.

However, now that I’ve been actually spending the last few weeks in 2018R3 heavily, working on a fairly large project (27MB project file)… man this thing is SO slow… it’s extremely hard to work in. Things I’m noticing:

Clicking takes 1-4 seconds to register. Every time. Opening a new tab takes many seconds. Many times when I double-click a control to edit the code, it moves a few pixels before the code editor opens. I have to eagle eye it constantly and undo the move, because the double-clicking is registering so slowly that it’s triggering a drag/move before it knows I’ve double-clicked. This alone is a HUGE issue, drastically slowing down my productivity. My neatly aligned controls and UI is being constantly fiddled with. Sometimes I don’t even notice it until much later, and it’s just lucky that I do see the controls mis-aligned.

Switching to the code editor is slow and cumbersome, but once I’m there, typing is even worse. If there’s more than 1-2 dozen lines of code, it slows to an absolute crawl. I’ve tested this on multiple Macs, all with modern builds and high-end specs, and always get the same result. Performance is just painful…

I know this has been discussed many times before, even by me. But basically this post has two purposes:

  1. To congratulate the XOJO team on the interface and improvements of the IDE visually and functionally. It is really feeling mature since the initial redesign back in 2014 or whatever it was.

  2. To beg, PLEADE, IMPLORE you now to focus on performance. This sluggishness is absolutely killing my productivity. It’s physically making me so much slower when working on projects, and mentally fatiguing me so much faster than if things were performing better.

Example: I made a change to a class and had to manually move code in about 100 controls throughout the project from one event to another custom event. This should have taken about 20 minutes. Bug it took over two hours, and I had to take several breaks. Moving through the error list, each click took 5+ seconds to switch to that part of the project and bring up the code. Then cutting the code, making a new event handler, pasting the code, and deleting the old event handler took over 30 seconds. Every single time. This is 3-4 moves with keyboard shortcuts that should take 3-5 seconds tops.

The slow response is also causing a lot of issues where I click something and press delete to get rid of it, and then the wrong control/method/etc gets deleted because it never registered my click. The whole thing is just a mess.

Is there any hope, a small prayer, that the next version(s) you guys are working on will really address this sluggish performance? It’s been a long-time issue, and I know you had other priorities. Where are we at now with this new release? If it was more responsive, it would be a truly great IDE and a pleasure to use.

Sorry to gripe, and again I want to say how happy and impressed I am with the work you’ve done in other areas. It’s really looking great. It hasn’t crashed on me at all, it’s stable, lots of little bugs and issues from older XOJO builds seem to be gone. It just needs to be more responsive, and it will be truly great.

Thanks for indulging my mini rant, and hopefully we can get some positive response from the dev team that they are indeed focusing on performance.

P.S.

This is definitely an issue with larger projects. When I make a new project, or open a much smaller one, XOJO is very responsive and feels wonderful. I almost cried at how fast it was when I went to make a change to a small admin app the other day. It was sooo nice! But in larger projects, it’s back to molasses.

Do you get different performance when NOT in Dark Mode?

Since you’re a pre-release person I suggest you work with whatever prerelease version is available and try it there too. Feedback on that version is even more critical.

Thanks Bob. Unfortunately the performance is just as slow in light or dark mode. I will check the pre-release section and see if they have any newer builds. I just know they’ve been mostly focusing on 64 bit, dark mode support, and fixing other bugs/issues with the IDE. And I can tell that has paid off a lot. Things are so much nicer than they were even a year ago. But performance continues to be a major issue, and I just hope they’re actively working on that, or will be soon.

I’ll see what I can do as a pre-release tester. I’m happy to share any diagnostics/reports/whatever they need if it will help them improve performance!

Personally I have never experience the IDE being “slow” to the point it was really noticable… .but what I have noticed (starting in 2018 at least) is the you click on a line in the editor, and your cursor ends up at the beginning to the block the line was in…

I am running Xojo 2018.3 on a 27in iMac i5 under OS 10.14.1 in Dark Mode. I am simply not seeing the issues you report. Can’t say that performing the actions you mention are instantaneous, but every one as you describe is completed in < 1 sec on my computer. This is true with a fairly large project as well. I can’t imagine working under the conditions you describe and I have no solutions for you. I can only testify that this is not the standard performance.

Dave, that is very strange. I’ve been having major performance issues over several XOJO releases now, maybe since the beginning. There must be something about my projects that is causing the issue. It’s super fast with new projects or smaller projects, but my two bigger/main projects are just terrible.

Dave, how big are the projects you are working on? I’d love to know if it was just the size of my projects (about 20-30MB), or something else specifically in the projects causing it. I’m not using any 3rd party plugins, either.

Just now I was testing things in light mode, and double-clicking three different controls moved all three of them several pixels off the screen before bringing up the code editor, which took about 5 seconds to come up each time. Going back to the layout editor and undoing the move took another 5+ seconds each time. Performance is only part of it — having clicks ignored or mis-registered is what is really killing me. Things are moving around on their own, or not being clicked at all, so I end up deleting/nudging the wrong object, etc

I’m going to take a screen recording of my performance and share it, to show what I am experiencing.

I have one project that Finder says is 47meg… and I have no plugins

Okay here’s a recording I just made. Notice how the controls are moving on their own almost every time I click/double click, or sometimes clicks are ignored all-together.

I quit and re-opened Xojo just before recording, and that did improve speeds from 5+ seconds down to 2-3 seconds when switching to code editor or navigating the library. But you can still see clicking on controls, dragging on controls, and typing in the code editor is insanely slow. The method I’m typing in only has 70 lines.

Video: https://www.dropbox.com/s/h4j1loym7qblt6v/XOJO%20Slow.mov?dl=0

So no one else is experiencing these kinds of issues? I’m wondering if I should make a new project and drag things in from the existing one a piece at a time and see how it affects performance?

I have read that a couple of times. People reported that doing that fixed some issues. I don’t know how hard will be for you to do that and maybe the results will not be what you expect. Good luck.

not sure what the video was supposed to show… but it was so small all I saw was you moving between a Window and code… with a bunch of clicking in the back ground.

What level of computer are you using…

Dave, I just watched the video again. It’s full size on a 5K iMac. You may need to download it from Dropbox rather than watch it in the browser. But it’s full size and full quality.

Running currently on a 2016 iMac 5K.

Did you not see the controls I click on moving by themselves, or how slow it was to drag a control around or type in the code editor?

No, I experience the 2018r3 slowness all day long. At this point, we’re all just out of breath.

But I don’t. So mileage definitely varies.

It seems clear that the issue isn’t affecting everyone, but there is significant performance loss for some users under specific conditions. I just wish I knew what those conditions were…

I’ve started a new project and am bringing things in piece by piece. I believe I have found (one of) the main issue(s). I will be reporting via Feedback ASAP.

Findings:

  1. As I add more and more things progressively to a blank project, performance progressively gets slower. There wasn’t “one thing” that impacted overall performance.

  2. The more tabs and especially windows open, the more performance slows to a crawl. Typing is almost impossible when you have two windows open. When things are kept tabbed in one window, typing only seems to slow down when you’re in larger methods, with progressively worse performance the larger the method.

  3. This one is HUGE: controls are responsive and can be clicked and dragged in a layout editor easily, until you have NESTED controls. I had a window with 40+ controls and it remained responsive. As soon as I added a small GroupBox and put a button inside the group box, the entire IDE slowed to a crawl, including switching between the code editor, typing in the code editor, and clicking/dragging/manipulating controls in the layout editor.

Try this:

Make a brand new desktop application. Add a PushButton to the window. Nice and responsive. Drag it around, double-click, add more controls, everything is great.

Now simply add one GroupBox, make it about the height and width of the window, and make sure the PushButton is inside. For me, performance instantly tanks. Dragging is extremely lagged, double-clicking misfires and moves the control around the screen, switching to the code editor and back is much slower, and adding new controls or moving anything around is barely doable.

This is probably the main issue for me. I use a lot of nested controls. I would imagine most people do. And if you have several windows open in tabs, each with nested controls, the IDE becomes very unresponsive. I’ve included a video showing how extreme the issue is: https://www.dropbox.com/s/sh5jkqmqwlfwfgb/Xojo%20performance%20issue.mov?dl=0

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

Thank you Alberto, I’m glad this has been observed by others and not just me, and it has been reported. I’ve been having performance/responsiveness issues in Xojo for a couple of years, but 2018R3 seemed way worse to me - and now I know why. I will hope for an update fixing this issue soon, and meanwhile I can limp along. Just glad it is being addressed.

And what is the speed in other applications ?

What I noticed (mainly with El Capitan) is…

The more application you run simultaneously, the slower they run… (lack of memory slow down the computer running)…

The less hard disk free space (even in a boot SSD) you slower your computer works.

But Xojo alone with 25 GB of SSD free space is not slow, even with a 30 MB (binary) project…

Xojo 2015r1 (and for testings a feature / method… with 2018r3)
El Capitan (.6).

[quote=417007:@Emile Schwarz]And what is the speed in other applications ?

What I noticed (mainly with El Capitan) is…

The more application you run simultaneously, the slower they run… (lack of memory slow down the computer running)…

The less hard disk free space (even in a boot SSD) you slower your computer works.

But Xojo alone with 25 GB of SSD free space is not slow, even with a 30 MB (binary) project…

Xojo 2015r1 (and for testings a feature / method… with 2018r3)
El Capitan (.6).[/quote]

What I’ve noticed that can make or break using Xojo is not really related to it. I had a couple of applications that scan directories for changes (Dropbox is particularly egregious, but also things like onedrive, google drive or comicstreamer). Performance was literally less than a fifth when these were running (even if there was no network so they couldn’t do anything really) than when not.

I’m not sure if this applies to any app that uses filesystem events to track file changes (also happened with git tools like sourcetree) but pausing or quitting them made a definitive difference in performance.