Feedback Case Number:
When I use command c and command v repeatedly on a MacBook Pro using macOS Big Sur version 11.1, I find that Xojo slows down until it freezes and Im have to force quit to restart.
Feels like a memory buffer fills up to a point where nothing can continue.
I can confirm that. I have done further testing with the code editor and think there seems to be something fundamentally âoffâ in the design of the Code Editor. However, I donât think itâs a pure âBig Surâ problem, but a general one.
First of all: I know that Xojo always points out to keep the code for single methods/functions in the Code Editor as short as possible, however I was interested in the performance of the Editor in the IDE and thatâs why I resort to this âextremeâ example.
For testing, paste a multi-line code (e.g. 3000 * the line Var i As Integer = 10) into the Code Editor once by copy & paste. This takes a few seconds on a MacBook Pro with SSD. Once the text is loaded and the syntax is highlighted, the code can be scrolled very quickly. However, if you try to place the cursor inside a line of code and make changes to the code using the keyboard, performance unfortunately fails in every way.
@Greg_O_Lone - It seems like every small text change in the Code Editor always causes the entire code of the current view to be changed and updated, instead of just changing the text of the current line and drawing only the visible lines in the Code Editor TextInputCanvas. This depresses performance tremendously. It would be much better if the Code Editor managed the individual lines as Strings in an Array. Then only the text of the current line could be changed and rendered via the index. This is much much faster than what the IDE currently seems to do.
Look how long it takes, until the Code Editor added all zeros.
They are individual lines. Itâs more likely that you are running into speed issues because of autocomplete. Whenever the cursor moves, the code editor has to determine where the cursor is and what is in-context at that very moment. It wouldnât surprise me that 3000 identical declaration lines make things slow because they all have to be parsed.
That said, make sure you are using 2020r2.1 as we fixed a couple of performance regressions that were introduced in 2020r2.
Thanks @Greg_O_Lone for the feedback. I know I only chose such an example so you can âreproduceâ it well. And as you can see in the video, I used version 2020r2.1 for it 
BTW: Happy and healthy 2021 @Greg_O_Lone
Wouldnât it increase the speed if only the current line, i.e. the one in which the cursor is located for the context, is always parsed?
You canât just parse the current line. Letâs say you have 3000 lines and you click somewhere in line 1500. Autocomplete has to look at all 1499 lines before that and the item parameters to determine if any of the declared variables need to be included in the menu⊠and it all depends on the context of where the cursor is in the line.
I wonder if there is scope for turning autocomplete on and off on demand?
Im sure that would help mimic the experience of those people who keep asking for the ability to see âthe whole code at onceâ in more text-based editors.
I can confirm this: it is also under Linux a normal effect. The used Memory is growing up until the System stops Servicing xojo. It has to do with not available Garbadge collection, it is a Price for the Usability of the IDE: while it is written in Xojo and not in C++ the IDE has no dedicated Garbadge Collection. But a better usability. Somehopw there is always a dead you will die.
@Greg_O_Lone not entirely true, I controled the effect on Mac and Linux and found out, that there is a leaky Memory Management. Sorry for that but if you are familar with JIdea or âclipse you will see that this Problem is not there in this IDEâs. So it should be clear that this is following to the fact that it is programmed in xojo and not C++ or Java. I am sure you know byself that xojo has not the Ability of fast calculation of String conversions. We made Tests with Xojo (2019, 2020, 2020R2.1). As Result there is not a quarter of the Speed of Java, not to speak about optimized C++ Code. And this is the point the problem relies in. Beside the fact that xojo is not doint Garbadge Collection in the needed mannor it makes exactly this effect.
Out of interest, have you tried comparing against older versions of the IDE?
Our own tests show that auto complete has gotten slower in just about every release of the IDE with 2019r2 being unusably slow.
A technique often used in live search fields is to only update the search results after the user has stopped typing. I wonder if a similar technique could help here? Only do autocomplete calculations when the user has paused in their typing for a sufficient duration.
And/or: the IDE should track how long the autocomplete calculation is taking, and if itâs taking more than X milliseconds, go into a âslowâ mode: in this âslowâ mode the IDE could still put up the ââŠâ elipses character onscreen, but only calculate and show autocomplete options when the user hits the tab key.
Thank you to all who have commented.
What I was doing when I found out he issue was to copy and paste over multiple lines, not on a single line.
I agree that memory management seems to be a fundamental issue that should be addressed. Garbage collection is a core problem for all languages. Maybe this is the answer?
All the best to everyone for the New Year - I wish you all health and good fortune.
Phil
Did you do a Feedback case? I wasnât able to reproduce the issue - I copy-and-pasted multiple lines.
Donât listen to rambling and whining.
It is creapy to speak about wining. Xojo IDE performance is comparing to others really worse, sorry. And they have to do something on it. Or do you really want to compare with IntelliâŠa or with EcâŠe? I donât think so. But that is the performance wee need to reach because programming needs this performance. We could repeat this on MacOS, Linux and Windows. On Windows and Linux even worse but okay. So: may be you are the lucky one without this problems, congratulations. But speaking about wining is in my view a real unfair beginning of behaving with forum members. Sorry.
@Thorsten_Stueker, @Philip_Cumpston: Could you please elaborate why you are missing garbage collection and think that the fact that Xojo, like most OOP based languages and systems, is using ARC instead could be a cause of the low performance? And what âfast calculation of string conversionsâ do you mean?
If you find a memory leak and made sure it is not your fault, this is not because of Xojo but because of a bug worth reporting. Might of course be a bug in Xojoâs frameworks or other internals, but in no case simply âbecause itâs written in Xojoâ.
@Greg_O_Lone: Thanks for your explanations! Admittedly I donât know the internals of AutoComplete. But in theory I could imagine some ways of buffering that would at least avoid repetitive processing of lines that cannot have changed in between two key strokes. Wouldnât AutoComplete allow similar things?
I miss Gabage collection because xojo is consuming Memory I can not freee manually. In the same moment xojo is not making it free. I see that it is to much data volume processed through xojo so it is a problem but not a showstopper in the most cases cause only a few people will have performance tasks like this.
It is reported.