Sluggish IDE navigator

The test involved pressing the keys qwepoi in sequence for 5 seconds and then timing how long it took for the IDE to stop inserting text.

I decided to run the test after trying one of the 2019r2 betas and found that the code editor could no longer keep up with normal typing. I repeated the problem in a brand new empty project so the number of tabs etc… was not an issue.

It might seem like a pointless test but it determines how efficient the IDE is and confirms this part is approx. 6x slower than it was two years earlier.

I’m sure it is related to the number of plugins we have but we’ve removed everything we can and the fact that older versions could keep up without a problem clearly shows that something has went wrong somewhere.

1 Like

How is it with NO plugins? I don’t have any, not even the Xojo ones, and 2020r1 and predecessors seem OK to me.

I actually find navigation in 2020r1 IDE faster (even with Dark Mode). I don’t use plugins.

Its been a long time since I tried but it is irrelevant as I cannot get rid of the plugins.

Not for production maybe, but you can for a test.

I just installed 2019r3.1 (the latest version I can run on macOS 10.11) without adding any additional plugins. I ran the test and it took the IDE 3 - 4 seconds to catch up.

I just tried a version of your test that I can actually type sensibly (“this is a test” 10 times) and the result is 0 seconds. I’m a very fast 10 finger typer. 2019r3 on High Sierra with lots of plugins.

running a sample from the command line (so you can delay it a few seconds before it starts capturing) can be useful in trying to figure out why its so slow for you and not for others

its not perfect but its way better than guessing

I haven’t seen it mentioned but has anyone with this issue tried restarting with the shift key down? This will disable stuff that ordinarily loads behind the scenes at startup and may offer a clue.

(Note: It can take an awfully long time to start, so be patient.)

I’ve profiled this using Instruments a few times and put the results in the case.
However, i’ve never profiled with just the standard plugins.

Xojo 2019r3.1 (default plugins)

6.66 s 96.9%| Main Thread

1.51 s 26.9%| CodeEditorCanvasNew.Event_InsertText
1.49 s 26.6%| —|_CodeEditorCanvasNew.ReplaceText
1.36 s 24.3%| ------|_CodeEditorCanvasNew.UpdateAutocomplete

1.17 s 20.8%| AppearanceAwareCanvas.Event_Paint
1.16 s 20.6%| —|_StudioCommandBar.Event_Paint

1.17 s 20.8%| DocWindow.Event_EnableMenuItems
1.17 s 20.8%| —|_DocWindow.EnableStudioMenuBar
1.15 s 20.4%| ------|_StudioMainWindow.StudioMainWindow.Event_EnableMenuItems

I had Xojo 2014r2 with our standard set of plugins open so I ran the same test.

Xojo 2014r2.1 (48 plugins)

3.44 s 99.0%| Main Thread

597.00 ms 15.7%| DocWindow.Event_EnableMenuItems
379.00 ms 9.9%| —|_EditorPaneImp.Event_EnableMenuItems
175.00 ms 5.0%| ------|_IDEApp.Event_EnableMenuItems%%o|

1.54 s 40.4%| CodeEditorCanvasNew.Event_InsertText
1.51 s 39.7%| |_CodeEditorCanvasNew.ReplaceText
1.34 s 35.3%| —|_CodeEditorCanvasNew.UpdateAutocomplete

Both tests involved spamming the keyboard for 5 seconds.
Xojo 2014 used 3.44s of time on the main thread while Xojo 2019r3 used nearly twice as much.

Edit…

I ran another test to see what AppearanceAwareCanvas was doing. It looks like 20% of the time is spent on drawing buttons
)-:

1.42 s 20.7%| AppearanceAwareCanvas.Event_Paint
1.42 s 20.6%| —|_StudioCommandBar.Event_Paint
1.16 s 16.8%| ------|_StudioCommandBar.PaintInto
1.14 s 16.5%| ---------|_StudioCommandBar.DrawItem
803.00 ms 11.6%| ------------|_Icons.CreateImageFromMaskWithTint
563.00 ms 8.1%| ---------------|_Icons.CreateImageFromMaskWithTint
|225.00 ms 3.2%| ------------------|_Picture.CopyMask
|139.00 ms 2.0%| ---------------------|_Picture.ApplyMask

I logged on to the forum to congratulate Xojo for the 2020 release. I, too have experienced ever-slower IDE scrolling as each release through the 2019 series came out. I just downloaded 2020.1 the other day and have been pleasantly surprised by the significant increase in IDE scrolling speed. Sorry to hear that others are not similarly blessed, but it appears - at least in my case - that they are making progress. Thanks, guys!

2 Likes

I’d be interested to see what speed your get with default plugins on the example>sample applications>eddies electronics>desktop>eedesktop project after saving it to whatever device your main project is coming from.

I don’t know how to measure the speed directly, but here is what I did - I opened Eddie’s Electronics in 2020.r1 and also in 2019 r3.2. In the left-hand pane, I turned all the arrows “down” to expand the source code fully, in both versions.

Simple scrolling of that pane has been jerky and imprecise in 2019 and back to when the IDE was completely rewritten. With this example, it is still very jerky there is a definite hesitation before the scrolling actually starts, then a continued jerky “jump” to somewhere in the program, leading to an “overshoot” when you are trying to get to a specific window or object.

Scrolling Eddie in 2020 r1 is much smoother, with no hesitation when you start the scroll up or down. I see noticeable improvement and it makes editing the source code much more pleasant.

The effect with the Eddie example mirrors what I see in my own source code. Julian, I’m not a professional programmer and program fo my own use, but this is definitely a step in the right direction.
I haven’t kept earlier versions of Xojo, so I don’t know if the IDE is as fast as way-back, but it’s much better in 2020 than in 2019.

Almost looks like its not caching them and only recreating them when colors or scheme changes
That would be a performance hit if it recreates them all the time

What exactly would you want me to test?

That’s what I was thinking.

Whatever you did during the instrument samples you posted above, typing speed?

Thanks everyone for the suggestions and visibility to this issue. I went back and plugged in my old monitor, zapped my pram and smc, restarted (obviously) with no other applications, turned off dark mode, and… well, it does seem a bit faster. Definitely in the workable range of functioning. Or I’m just getting used to the lag. Under a second for sure. Unfortunately, I didn’t do any formal testing as the issue was so pronounced it seemed unecessary. But I was clearly at almost two seconds to get a response from the navigator to maybe a half second to 3/4 of a second now.

To be clear, I’m only talking about selecting items in the navigator. I never got far enough to do any typing. I don’t know that I’d call the problem “solved” but I’m in the acceptable range of latency. And I gather from Greg’s post that this is a known issue that they haven’t given up on.

What plugins did you have during this test?

I didn’t do a formal test. It has the standard plug-ins that come with Xojo.