Now that 2021 R1 is out, here’s the updated native M1 speed tests:
Native M1: ~0.4 seconds, both with or without toolbar showing
2013 i7: ~0.8 seconds, both with or without toolbar showing
(…again both on Big Sur.)
2 Likes
Upgraded to new version, my app crashes when closing a movable modal window. 1 line of code in my close button…me.close()
My app toolbar does not refresh on closing movable modal window. It does if i convert the window to document.
Same sluggishness.
Yep i am having some tough time when people say their ide is fast. I just saw two videos and the app is not as slow as mine but still slugish. 1 to 2 seconds is not fast…but i can see people getting used to it.
Thank u all for spending valuable time. Mark spending valuable time doest not give u the right to imply some one is lying or that is strange because they do not share a picture.
I have spent hours doing my own debugging to see why the ide is slow, i have mentioned NDA status… i think i am doing my part. Heck i am doing more debugging and troubleshooting here with Xojo a paid software than with any other free open projects i have used or work on.
Again, i appreciate everyones time to help me fix this issue (remember i am not the only one mentioning slowness, there is other post here and since 2018 and longer) but please dont feel force to help me. I can and i am troubleshooting this myself. Of course any of the guidance here is greatly appreciated and i thank u guys a lot!
You realize that this closes the button, not the window, right?
1 Like
@C_P We found a speed problem with the code view tonight on another thread. Having no screenshots or video of the problem is honestly a nightmare so instead could you answer a few questions?
- What resolution is your desktop and what scaling are you set to?
- Are you in dark mode?
- Do you use workspaces in the Ide?
- Have you tried my suggestion above and removed windows/controls from a copy project until the speed improves?
- Does it improve?
- Do you see this with a new project on a fresh reboot?
- Do you unpin/float the inspector/library?
- Do you have background images on your windows?
- Do you have background colours on your windows?
- Are the selection of certain controls slower than others, if so which are the slowest?
- Do you use container controls in your project and/or on the window?
- Can you sample the process while its having this issue and post it here? See 2021R1 IDE still poking along - #2 by Mike_D for info on that.
- Are you able to post a screenshot of your IDE layout with sensitive information blurred out?
- Here’s a demo project I knocked up based on the description you made of your project, do you see the speed issue when using any of these windows? If so, could you make a video of it. Dropbox - File Deleted - Simplify your life
2 Likes
Yes, thats a typo on the forum… not on the code. In the action sub of the button i have coded : Self.Close()
Thanks for pointing this out Greg!
The IDE has suffered from lag in various places for the past few years. I have several versions installed on one of my Macs and it is quite easy to see the difference in performance. The lag is very noticeable if you move from an old version of RB / Xojo to a recent version or you are coming from a different IDE. Maybe the computer is partly to blame but I think the main cause is the IDE / Xojo framework itself as I can repeat the problem on too many Macs for it to be just the computer.
Unfortunately, if you want to use Xojo you have to live with the various IDE and framework quirks / issues / regressions as there appears to be little effort being made in fixing them.
2 Likes
Xojo Inc. is trying over and over again to fix it. But as soon as one issue is solved another one arises in the next release of the IDE.
I’d not say that there’s little effort, but the IDE is really not a good example of what Xojo wants to be able to do…
2 Likes
I am starting to see a similar behavior in the Win IDE which I am not used to yet. When Im debugging it is super common for it to take 2-3 minutes in what I call “Hang mode” where I know its hitting a break point I set, for instance in the application open event so not even deep in. Neither the IDE or the application are responsive at all during this time and it doesn tmatter if I click on the IDE window it takes a long time to get into the initlal break point. Subsequent breakpoints are instant.
I suspect it’s the way Xojo uses to initially communicate between the IDE and the debug app. I think it uses multicast to establish a connection, and that this use of multicast is not reliable. The same delays sometimes occur when you use remote debug with the IDE on one machine and the degug app on another and I think it’s for the same reason.
I don’t know enough about multicast to understand why, though.
I just want to pop-in here and say something, I’m not excusing Xojo nor the little IDE quirks… but…
I had to do some Swift in Xcode 13 on Monterey (on a Intel i9)… Ughh, that is slow and janky. When I went back to Xojo, it felt light and snappy, also the language (API 1) feels less cumbersome than Swift.
2 Likes
Hmmm… that is strange. Xcode is really much snappier and faster compared to Xojo. In fact, it 's way way way faster in any aspect.
You can of course argue about whether Swift is harder or easier compared to Xojo. 
2 Likes
Other than perhaps in discoverability. I get hopelessly lost every time I open it…
2 Likes
BUT Xojo is not Xcode, it is a tool to work with Xcode for development
Xojo is not Xcode, It is not Visual Studio, It is not other Tools
For me that is enough said of course I know there will be replies and I respect that
Right now this installation feels like it’s loading from a spinning disk; I guess it’s because Xcode has gotten so fat, there’s a lot to load. Shame Apple has dropped App plugins, otherwise some of the functionality could be loaded on demand.
I need to find another application that will colorize .h files nicely.
You’re right, I can’t really argue as I don’t write any Swift, only try to read it. Many of Apple’s sample code is now only in Swift. It seems like the focus of Swift is get as much as possible on a single line and readability be dammed, mind you, with the next version of Swift, you’ll probably have to re-write it all anyway.
2 Likes
I never wrote any code line with Switf or X-code, but I can say I wrote and maintain uptodate 11 applications made with Xojo for many years. I meet on forum some people who wrote a single program with Switf / Xcode and who abandoned it after 2 or 3 years. And their job was in relation with software development, my job has nothing to do with development.
For what I read, it seems that Switf is easiest for some particular function, but Xojo is much easiest for a whole application.
That’s utter nonsense, sorry.
You clearly never touched Xcode and Swift. 
Well, with XCode you can’t even do a simple app that holds a couple of hundred passwords anymore. Or what did the 1Password developers say why they can’t use ObjectiveC/Swift anymore? And you need 500 devs for such a simple app.
1 Like
Sarcasm for sure. 
1 Like