I started working with 2018R3 on quite a big project. Felt good, until I had a runtime-exception while debugging my project.
After I stopped the project, I faced extremely slow typing speed. So slow that is got unworkable.
I restarted the IDE, loaded the project again, and from the first keystroke the code-editor was responding very slow again.
I copied the project to my laptop and loaded it into my 2018R3. Shock, from the first keystroke very slow too.
I got my last backup back and it showed up working fine in the editor.
I repeated the test, had the runtime error again, and from that point my project got defect again. Very, unworkable slow typing speed.
I am using 64-bit setting.
Anybody experiencing the same ? Project: Win10 64-bit
It is all fine here too. But you seem to have a reproducible demo that would surely be worth gold to Xojo. I’d suggestyou file a bug report with your project attached privately. Let me know the case number & I’ll assign points to it.
The trouble is, I had only while debugging and hitting a runtime error. The project became unworkable due to a very very slow typing speed. My friend, also a professional Xojo developer was a witness, and we both did not understand what was causing this. Then we moved the project to my Macbook on a VM, and we had the same trouble. Next we moved it to his native Windows 10 machine and we did not see any issue at all. After fixing the cause for the runtime error, which occurred in an the action event of a timer, I did not encounter the issue anymore.
And today, after quite some debugging runs the slow-typing-beast was back again.
Shutting down the IDE, restarting it again with the cache removed, loading the project again and problem is gone. Finally it seems to be the same issue as we have to deal with for long time already.
2018R3 with the project loaded takes 667 Mb of memory, according to the Windows taskmanager.
The slow typing speed of Xojo is very well known and is a plague for several years now. As long as Xojo inc. uses their own Xojo tool, this will continue.
Before I trenched Xojo because it became too unproductive for me I typed the code in Sublime Text Editor and then copied it into the Xojo IDE. That was the only method to loose not too much productivity.
This had a couple of advantages :
You can perfectly select dimmed variables
You can add Xojo keywords and commands
Your line endings are respected.
This is not an ideal situation but at least you will not get frustrated to reduce your typing speed to the one of a snail.
To be honest, I can’t understand why this slow typing behaviour is not a priority for Xojo. It seems easier to accept unproductive typing speeds than looking for better alternatives. BASIC remains the Beginner All-Purpose Symbolic Instruction Code solution (on which Xojo language is based), not suitable to write a UI in.
Hi Chris, i like how the msgbox suggestion come out next time. I use Tincta Pro for the last few years for creating my SQL statement before put it into my SQLiteManager. I don’t think Tincta Pro do suggestion like Sublime Text, but they do have syntax coloring.
thanks for giving instruction on how to do what you mention
I have been seeing the slowing down of typing over the last couple of days. I wasn’t looking for this issue, as it just sort-of ‘happened’.
There is no example program that seems to replicate this issue, and this is what seems to happen. I work on the computer with Xojo during the initial startup of the computer during the day and the typing speed is respectable for the first few hours. There are many different programs that I am opening and closing during this time, as I am updating many declare functions. After about 4 hours or so, then the typing speed starts to decrease. The solution seems to be restarting the computer. Turning the computer off only seems to work with Windows ‘Fast Startup’ turned off, as this refreshes the Windows OS instance. With Fast-Startup left on, then the typing speed remains low. I couldn’t see a significant change in memory usage, so I am not sure what is causing the slow down.
Also, the Ctrl-S and Ctrl-R seems to also slow down. My rote memory for saving and running programs from the IDE works perfectly fine at the start of a reboot, and near the typing slow down, I must pause between saving and running the program because there is a significant delay. Again, rebooting with Fast-Startup in the off position seems to help again for a couple of hours.
I have no scientific proof, and this is just what seems to happen.
edit: “Again, rebooting with Fast-Startup in the off position seems to help again for a couple of hours.” this statement should be Again, rebooting, or shutting-down and starting up with Fast-Startup in the off position seems to help again for a couple of hours"
@Eugene Dakin - you’re better in writing down precisely what you see than I am. A few weeks ago I said on this forum I restart the whole thing every coffee break, and that’s in fact what you say too.
With release 2018R3 the Xojo team has done a great job, although it took me 2 days to upgrade a 2017 project to this latest version. and 64 bit. It’s worth the investment since the customer will experience the improvements right away.
Think now it’s the time to for them to finally research and solve this problem, since we struggle with it for 2 years already.
Paste those 10k lines in from another editor because its a lot quicker than using the IDE however you can probably make a drink during the paste as it takes about 45 seconds here.
Obviously this isn’t best practice, 10k lines in a single block of code without breaking them up isn’t ideal however if this simple example is indicative of what happens as the project gets “wider” instead of “taller” then the issue is there and repeatable.
What extra processing in there on 10k comments over 1k comments? Shouldn’t they just be ignored? Here’s hoping that the “container” for the code isn’t expanded 1 character at a time as you type.
Oh and when you get 30k lines, typing speed is 2 characters per second.
All that being said, getting to the bottom of why some people see this with waaaay smaller projects would be neat.
Maybe some users need access to a logging build that tracks and reports usage, speeds of calls etc. that they can submit after seeing the problem to try to narrow things down?
I’m no expert, but it looks to me like on every keystroke it’s calling ReplaceText and ReindentCode and I wonder if perhaps one or both of those commands is processing the entire text block on each keystroke?
Also, there’s more:
if I try to do an Edit/Cut to remove those 10000 lines, the IDE locks up for about 45 seconds, with these items in the sample stack:
2668 StudioSourceElement.StudioSourceElement.HandleCommand%b%o<StudioSourceElement.StudioSourceElement>o<Commands.Command> (in Xojo) + 1054 [0x10b82e5ce]
2668 CodeEditControlElement.HandleCommand%b%o<CodeEditControlElement>o<Commands.Command> (in Xojo) + 28240 [0x105bf2910]
2668 CodeEditorCanvasNew.DoCut%%o<CodeEditorCanvasNew> (in Xojo) + 512 [0x11148e6f0]
2668 CodeEditorCanvasNew.DeleteSelection%%o<CodeEditorCanvasNew>bb (in Xojo) + 11143 [0x111486d57]
1208 CodeEditorCanvasNew.DeleteLines%%o<CodeEditorCanvasNew>i8i8b (in Xojo) + 1087 [0x11148320f]
! 599 CELine.matchBelow.Get%o<CELine>%o<CELine>i4 (in Xojo) + 162 [0x105c05232]
! : 524 WeakRef.Value.Get%o<Object>%o<WeakRef>i4 (in Xojo) + 44 [0x10466408c]
! : | 293 RuntimeStackCheck (in XojoFramework) + 139 [0x113a55ddf]
! : | + 273 unw_init_local (in libunwind.dylib) + 138 [0x7fff91ca49a9]
! : | + ! 177 libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::setInfoBasedOnIPRegister(bool) (in libunwind.dylib) + 62 [0x7fff91ca49f2]
I agree that 10k lines in one method is stupid, but these may be good edge cases for testing to try to profile and improve performance as much as possible.
Just ran into this issue myself for the first time. All of a sudden the whole IDE became very sluggish. Waiting 2-3 long seconds, just clicking from one method to another. Or from one button to another. Quite a mystery at first, but I figured out my problem. I doubt it will solve this whole issue, but here’s what I discovered.
Saved as a binary file, my project has been in the 200k area. After the sluggishness started, I noticed my project size had grown to over 1 meg. I’ve been working with some large JSON files. So to save time, rather than going out to the server for a fresh download during every test, I put the JSON data in a textbox. Turned out that was the problem. As soon as I deleted the text box, (with had a huge amount of test data), the IDE once again resumed its normal response time.
My best guess is this: internally objects are not stored a relational manner and thus, every edit may require rewriting the a large portion of the app internally in memory. If this is true, then the larger a project becomes, the more an issue this is.
Maybe rather than updating the app (internally) with every click and keystroke, it might be more efficient to update only when switching from one object (window) to another. So the delay would only happen when switching methods, not when typing code, or changing focus from one button to another.