if you’re on macOS you can use quicktime payer to record the screen
and activity monitor to record a sample of what the app is doing
For me on my late 2012 iMac (core i5 2.9GHz, 8GB ram, macOS 10.14.4) the Xojo IDE is at best sluggish(1). I have to repeat double-clicks so many times for them to actually work, and that is on a newly installed OS.
I have myself wrote a kind-of Xojo IDE in Xojo and it was much faster than the official IDE. And I am not even a very good developper!
(1) Besides the fact that the Xojo IDE itself is the crappiest IDE I have ever seen.
@Stephane Mons:
A machine from 2012 is way too old.
Mojave with APFS is slow.
8 GB is borderline for Xojo.
What are you doing with your doubleclicks? I’ve never seen this before.
Agree on (1).
@Beatrix Willius How could 8 GB be borderline for any programming language? It is just pieces of text that need some formatting. Honestly it shouldn’t take mush CPU cycles!
About the double-clicks, I think that the IDE is actually using Microseconds() instead of the time stored in the mouse NSEvent. So
the slower the IDE is, the less it is able to catch double-clicks!
It shouldn’t be, and in fact is not with older versions of this IDE generation. It’s incredibly fast and responsive with the previous generation IDE, as well as fast with a number of other tools. (I just sold a secondary/backup 2011 MBP.)
I hate to pile on the criticism because there’s so much to love about Xojo and I know the Xojo team works hard, but I’ve never understood this IDE generation.
Coming from another language it might be easy to dismiss the previous Real Studio IDE for its lack of some of the more advanced features that are found in other IDEs. But I absolutely loved it and loved working in it. Why? It stayed out of my way. It was very fast and responsive. The functions I used frequently were (literally) at my fingertips and I never felt like I was hunting for anything. When I was in the zone it just did what I asked without delay. Typing and auto complete were wicked fast, the toolbars were great, the property list was good (could have used some enhancement but what was there worked well), back/forward worked, etc.
Combined with REALbasic/Xojo’s framework, which is literally a programming example of Goldilocks’ porridge (not over engineered yet not too shallow) I was incredibly productive in that IDE.
The new IDE has some very awkward UI decisions. But worse it has always struggled with lag. It gets better, it gets worse…but it’s just not “snappy fast” like the last one. It literally drags productivity down. I don’t know if the performance issues are baked into the architecture, or if they could be solved with a minor overhaul. But I wish Xojo could take an upgrade cycle and focus on nothing but IDE performance and memory stability.
FWIW, Xojo is not the only one. Older versions of Visual Studio are more responsive than newer versions, and the last couple of releases can take a day to finish installing on your system. JetBrains feels like you’re trying to run a modern IDE on a 386 PC. Sometimes I wonder if the resurgence in text editor popularity is due entirely to the loss of performance at the IDE level. It seems the only major IDE which has remained fast is Xcode.
Its not JUST the programming language
APFS, whatever mojave does for Dark mode if you’re running dark mode, etc IMHO make mojave slower in general
Add Xojo on top and it does use older fie system API’s and it does get noticeable
I would also hazard a guess there are some older UI apis that may contribute
Its why on the EXACT SAME hardware, my old MBP late 2012 model*, on 10.12 the IDE is snappy, 10.13 is pretty decent, and 10.14 in light mode is OK and dark mode is … bearable
The ONLY difference is the version of macOS I boot
*MacBook Pro
Model Identifier: MacBookPro10,1
Processor Name: Intel Core i7
Processor Speed: 2.7 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 8 MB
Memory: 16 GB
Boot ROM Version: 255.0.0.0.0
SMC Version (system): 2.3f36
I have to agree, any half-way sophisticated IDE these days is a performance and/or resource hog one way or another. Which is why I also keep a decent and simple text-editor around at all times (TextPad on Windows and Textastic on Mac), for those cases when something goes south, or you just need a quick peek at some code from another project.
Also, don’t skimp on CPU, RAM or your SSD when buying new hardware, if you can help it - regardless of what kind of programming you do.
I’ve only recently returned to Xojo, so I’m using 2019R1.1 on the latest versions of Mojave and Windows 10 (Bootcamp style with a mid-2015 MBP, 16Gb RAM, i7 2.8Ghz CPU) and I get much better responsiveness from Xojo than Visual Studio 2010 & 2015 and the latest JetBrains tools on my employer’s machine (late-2018 Dell Precision Laptop with 32Gb RAM and i7 3.6Ghz CPU).
The Xojo IDE is not perfect, but it’s much more satisfying for me than a lot of the other tools I’m working with lately.
Maybe I’m just lucky, but I’m happy 
@StphaneMons : you try to build/run a large project, then watch how the RAM climbs up and up on each run. Then tell me that 8 GB is enough to run half a dozen apps and Xojo. I have both an iMac with 32 GB and a MacBook Air with 8 GB. The Air can do my large project barely. The IDE isn’t the problem but doing a run is fairly slow compared to the iMac.
I still think that there is something else going on. Plugins aren’t the problem as I have almost every plugin under the sun. Is it length of method? Complexity of classes? Number of open tabs??? If you have one of those, is then everything slow?
As a test I copied the text of a method dozens of times. Yikes, typing gets awfully slow.
When I launch Xojo with WiFi turned off or with my router off, I get the impression that Xojo slows down.
MBP 2014, Mojave and Xojo 2019r1.1
@Carlo:
Xojo calls home at run time (check with the version you use when it calls home exactly, and what he do on your back/silently).
*
It certainly also check if Internet is online for the Language Reference (unsure of that one).
At last, it checks if the Xojo cache folder is there and eventuallty creates it and populates it (with local LR and other stuff).
Remember: we are developers here, not simple users; we are people who knows how things are done internally (or we are supposed to be
) 
Example: todays date is 2019-06-02, but not for eveyone around the world some have a lower year value, some have a higher date value (and in ome countries, they use multiple year numbers ) for some Christmas is in December, for some others, Christmas is in janary AND some do not know what Christmas is ;).
Edit: *
Load a certain text file (with emoticons for example) with internet off, then do the same with internet on: you may end with a Font download without even asking it
And I do not talked about what do your iPhone on your back (just read macrumors.com and some others)
[quote=439385:@Graham Busch]I say it’s the inspector as it will be sitting at 13 gigs and 1 or 2 gigs compressed paused in code and when using the inspector I get the beach ball and the memory jumps to 20+ gigs pushing all other apps into compressed.
[/quote]
Look at your computed properties. When you pause execution, the inspector calls any computed property getters to populate them in the inspector. If you have computed properties that assume a certain state, there could be issues. (been there)
I’ve had issues before where I set a breakpoint in the constructor and it would crash the app because a computed property’s getter assumed that an object it relied on already existed, but the object was not created until the open event.
Might also be a good idea to run the Leaks instrument in Instruments.app… maybe also Allocations to see where the memory is going?
I read this discussion with interest, and I ask myself after reading “Is this acceptable behaviour for a paid application like Xojo?”. There is so much competition for Xojo. Still, the Xojo team assume they can afford all this buggy behaviour. A few days ago we saw Scott Boss leaving which should ring alarm bells with the Xojo team.
The reality is that it takes years for Xojo to solve bugs; some are still not fixed. The problem is they wrote the IDE in Xojo, which was an excellent marketing decision. However, at this moment, their development tool went past its limits. As long as they stubbornly resist using another language to write their IDE in, Xojo will remain a sub-class tool. Where was the time RealStudio was a great tool? This is the traditional example of why changes are not always good thing!
My analysis is different. For me, it is not a matter of tool used toc reate the IDE. Using Xojo to create the IDE is a good idea. Pushing the idea to its limits is a better idea. *
Where was the time REALbasic was a great tool ?
This is a far better question: REALbasic needed far less engineers than Xojo. It have far less targets (two at first, then 1, then 2, 3 ).
- As an example, The IDE uses PopOver(s), but do not expose them to us four our own use
Quoting out of order…
I couldn’t disagree more. Xojo should be perfectly capable of building a fast, responsive, memory efficient IDE with the feature set we see in the current Xojo IDE. As for solving bugs, I don’t want to say it’s entirely a manpower issue because architecture decisions and initial code quality can greatly affect debugging difficulty. But it is very much a manpower issue.
Real Studio was written with REALbasic. I can’t think of any major performance loss at the framework or compiler level with the name change to Xojo. And compiled code got faster with 64-bit support. It’s the IDE that was brand new.
With the exception of Xcode the competition is failing in many of the same ways. So are applications in completely different markets. (Try performance testing today’s MS Office against MS Office from 2001 on a G5.) I want to say it’s not acceptable for Xojo but then I have to say that about wide swaths of the industry, often including what should be simple web pages.
Having been in this industry longer than I care to admit, I’m honestly puzzled at the dramatic speed losses over the past decade. Is it due to excessive abstraction? Overly complicated design patterns? Lack of focus on basic algorithm efficiency in CS courses? Although macOS changes are likely responsible for the most recent, stinging performance issues (as Norman points out), you can’t blame OSes in general for either the Xojo IDE vs Real Studio IDE or for so many other applications which have slooooowed down over the past 10 years.
Just to be clear, a large swath of the IDE code base did not change when we released the Xojo IDE in 2013. It was mostly a facelift. Unfortunately we also made the transition to Cocoa in the same cycle which made it extremely difficult to track down speed related issues because we couldnt always tell where the issues were coming from.
That said, we have been looking at some of these speed issues already this cycle, and had been even before this thread started. As soon as we feel theres something stable enough, well get it out to the pre-release testers.
Nightly builds released to testers on the understanding that they could break projects or flat out not work would help here. Those above could already have tested their projects against it and instantly let you know if you’ve solved the problem or not.
I personally have been waiting for features that you implemented before the last release and I could have been testing those extensively by now using a version very close to the last stable release on projects which I don’t care if they crash or corrupt.
I’d hope that after being around 20+ years you at least have an automated nightly build process and could spit diff’d zips out somewhere.
Having time to reflect on some of the recent game breaking bug that have made it to production recently, I’d hope you’d seriously consider giving testers more time with the changes.
Weve been down that road several times in the past and it bites us each time. We are inevitably contacted by several users who didnt understand the phrase this could break your project being equal to unrecoverable.
Weve heard from our customers that things sometimes dont get enough testing time. Starting in 2019r1, we ended the practice of adding new things to the current release cycle once weve reached beta and created the release branch. This means that things will get fixed during a release cycle, but may not be available until a future release. Keep in mind that in our ecosystem, just because something is marked as Fixed or Implemented does not mean that its slated for a particular release.
Absolutely. Our builds have been completely automated since 2015. This still does not mean that every build is ready for end-user access.
[quote=439339:@Greg O’Lone]How are you coming to this conclusion? If you have reproducible steps, Id love to see them.
Heck even a movie taken at 2 or 3 frames per second from when you launch to when it gets in this state would probably be helpful.[/quote]
I was able to get a sample of the app running while the beachball was showing for 5 or so seconds when selecting a method in the IDE. 26Gigs being used, then drops down to 13Gigs. Added to feedback
[quote=441436:@Graham Busch]I was able to get a sample of the app running while the beachball was showing for 5 or so seconds when selecting a method in the IDE. 26Gigs being used, then drops down to 13Gigs. Added to feedback
<https://xojo.com/issue/56056>[/quote]
Hey, the sample is great, but it would still be helpful to see what’s leading up to this problem.