I’ve just removed all the plugins other than the stock ones that come with Xojo - still seeing very slow typing. I’ve attached a sample of the process while the slow typing was happening to this bug report: <https://xojo.com/issue/40564>
I think I was one of the first reporting slow typing when Xojo came to life. To be honest I learned to live with it. 
I never found a solid way to reproduce it all the time. It happens with small and big projects, with and without plugins, with small and big methods, … in short … a nightmare to fix.
Nightmare to find
Once I can find it fixing it will be easier
I have a friend who always said “Rocket science is the easy part. Rocket surgery is hard” since things tend to go boom in rocket surgery 
I should ask Asher if thats true
Hopefully the sample of the Xojo process I added to that bug will help.
Kimball, does it do it with autocomplete off? I can see it on my 2012 10.9.5 rMBP, but with autocomplete off I don’t see it.
FYI, the slow typing problem we had in a beta over a year ago, was WAY worse than this. On Windows there were times when there was about half second delay per character, before they fixed it.
I thought that after lots of discussion during the beta, this was the reason that you decided to add the ability to turn off Autocomplete (in the Coding preferences tab) - as a temporary solution until the real one is found.
Have those of you having this problem tried turning it off?
EDIT: Hah! Merv beat me to it…
[quote=222804:@Merv Pate]Kimball, does it do it with autocomplete off? I can see it on my 2012 10.9.5 rMBP, but with autocomplete off I don’t see it.
FYI, the slow typing problem we had in a beta over a year ago, was WAY worse than this. On Windows there were times when there was about half second delay per character, before they fixed it.[/quote]
Yes, it is still a problem with autocomplete turned off.
well that rules out what I would have guessed was the prime suspect 
I submitted a project in Feedback that shows the slowdown 100% of time for me. Does it not do the same for you?
What OS version are you on Kimball ?
This sample is radically different than the others
not at all 
go figure
Pah! I presumed it was because of the huge module (lots of methods) and have begun to separate said module.
I have a killer app that is far to large to compile - it mostly wont load if I’ve been working for over 15 minutes its so big
And I never see it slow down either
Hence why this is soooooooooo frustrating
The cause appears to not be “the common suspects” like autocomplete might be
I can get worse than 500ms delay sometimes. I just realized that I never actually used the checkbox to turn off autocorrect to see if it made a difference. In my case, at this particular moment turning off autocorrect results in it performing just fine. So whatever is messed up in my app is part of the autocorrect system. At least in my very large project. I was getting even worse speed earlier today but I just restarted for unrelated reasons and of course I cant duplicate that at the moment.
When that comes back after some work tomorrow Ill try turning autocorrect off and see if that makes it go away.
A couple of other observations that Ive made in other threads about this, after a while I start to get really strange autocomplete behavior. It no longer recognizes things. I can autocomplete a class name, hit the period and then nothing. It wont admit the class has any properties or methods. That can happen if you have syntax problems above that keep it from parsing out where you are properly, but Ive made sure thats not the case. It autocompleted the class name just fine, but then conks out.
Yesterday it started autocompleting just random numbers for me. I posted a screenshot of it in the feedback report offering to complete the number 255. Could it be that my autocomplete tree is filled with random stuff far and above the load of globals and locals and plugin methods that youd expect to be in there? How could I tell?
Lastly if Im typing inside a line rather than at the end of it the typing speed is just fine. For example if you type a space and then backup one character and type it goes just fine. In that case you can still hit the tab key to popup a menu of potential autocomplete options so I feel like it must be still following the tree, yet it works just fine. The only obvious difference is that the grey type ahead stuff isnt rendered in that case.
[quote=222836:@Norman Palardy]What OS version are you on Kimball ?
This sample is radically different than the others[/quote]
That was sampled on El Capitan 10.11.0. I just upgraded to 10.11.1 before I packed up to come home for the night. I can check performance on 10.11.1 later this evening.
I’m still on Mavericks. I know this doesn’t solve Kimball’s view of the problem, but for me the culprit is Autocomplete. If I turn it off, I find that the buffer is able to fully keep up with even my nonsensical random typing that probably equates to 200 words per minute. Off course with, autocomplete off, I can’t actually finish one line of code, but that’s another story.
That sample has … well … crap in it I’ve no idea wtf it is or does and its all way down in the guts of OS X api calls - miles of it
That suggests I’m going to need to run the IDE with profiling on on 10.9, 10.10 and 10.11 to see some of these differences
Autocomplete is USUALLY the culprit as it does a LOT of work every time you type more because what may be possible as a completion may change on every keystroke
I’ve seen this - cases like <https://xojo.com/issue/11761> where on one line its fine & the next its messed up
[quote=222861:@James Sentman]Yesterday it started autocompleting just random numbers for me. I posted a screenshot of it in the feedback report offering to complete the number 255. Could it be that my autocomplete tree is filled with random stuff far and above the load of globals and locals and plugin methods that youd expect to be in there? How could I tell?
[/quote]
You really have no way to tell but I can’t say I’ve ever seen that
About the most useful thing you can do at a point like that is take a screen shot and write a bug report with as much detail as you can about the context
The more detail I have about the circumstances, project, what you’re typing - literally EVERYTHING - the more likely I can craft an example that can reproduce it
These ones that are hard to track down really require that kind of detail as everything may be relevant.
Ah and include things like amount of RAM, SSD or HD, and specs
Again this may all prove relevant
Kimball, try this and see if this is any better. Move the cursor to the left one character ( this is a com|m ) and then start typing and see if behaves any better. For me it works perfectly like this because it suppresses the lookup on the autocomplete.
Uh-oh, I am seeing similar problems on Windows in a tiny test project. I really hadn’t noticed it during the whole beta cycle, because I don’t usually type very fast. But on Windows, if type really fast nothing appears until I stop typing. Then 40 or more characters all appear at once. Really the whole entire code canvas is sluggish, including marking text (FB# 41093, which I filed a couple of weeks ago). There is something definitely going on here and I don’t think it is related to OS X.
On WIndows with Autocomplete off it is better, but not perfect. On OS X, it is perfect with Auotcomplete off.
What is also interesting is if I click in the Find TextField at the bottom and start typing there, it is lighting fast. But if I click back up to the code window and type, sluggish again.