Not sure if part of the issue (if internally the cursor position is used during the IDE updating process); however, at least on the Windows IDE… if you scroll code within a method, etc. and the cursor should go off screen… it doesn’t. It acts like it’s hovering over the text when it gets to the top or bottom of the page where it should be scrolling under at the position it was left at.
I see that as well.
Disabling autocorrect on the Mac improves the speed but not to the level of R2 - it’s still pretty sluggish. Placing the cursor to the left one position as @Merv Pate suggested also improves the typing speed. Looks to me like autocomplete is at least partially responsible.
I’m using El Cap. Are people seeing this on Yosemite too?
Yes
I posted a screenshot of the 255 autocomplete in the feedback thread <https://xojo.com/issue/40564>
Ill try to gather some further info and will keep an eye out. Im about to start work for the day so as the cruft accumulates and things get interesting Ill take some more 
Ill do some more playing with the things Im seeing more than once in the tree. Some things you expect to see multiple times, if a method has several different parameter options for instance I see that they are all in the tree, but in one project in particular Im seeing that a whole group of windows I created are listed twice. I mentioned that in the feedback thread too. A window cant have different parameter options or anything so I cant immediately think why it would be listed twice. Its only listed twice if I have only the first character of the name currently typed and then hit tab. As soon as I type a second character of the name the duplicates are no longer shown. Which is equally weird The first time I saw this I clicked on the first one and it completed properly, and when I clicked the second one the IDE crashed. Theres an auto generated bug report for that too and I see youve already requested more info for it. But after it restarted I was no longer able to make it crash, it just autocompleted fine for both entries. Ill try to get you more info there too.
Id be happy to work in a development build that had a way for me to dump the tree to a file to send you or something if you think that is likely any part of the problem.
[quote=222948:@James Sentman]
Id be happy to work in a development build that had a way for me to dump the tree to a file to send you or something if you think that is likely any part of the problem.[/quote]
There’s no “tree file” accumulated
To do anything useful I’d be writing out a very large log file on every keystroke and then it would be nearly impossible to tell if we’re seeing slowness from the IDE or the logging
I’m busy profiling the IDE itself again and seeing what opportunities I can find
But please do keep posting additional findings as I cant tell what might reveal another opportunity for improvements
well… I thought youd give me a double secret keystroke or a menu option I could hit or something.
With my typing speed i don’t see any slowdown because of my stiff fingers my speed is …what speed?
But what i noticed is that when i autocomplete a command or class or something and confirm with tab for example ‘msg…’ and then after the first tab the word is autocompleted and i press again tab the whole IDE is repainted. On my pc you can see that very clearly but i guess that on a Mac this is not visible because of the double buffering. However this could be a reason for a slowdown.
We do try to repaint as little as possible BUT the one spot we have no idea how much to repaint is when the autocomplete popup shows as its another window open on top
So we redraw the whole thing
However that doesn’t seem to be what people are reporting
Still slow when I typing in the middle of a line or even just 1 character away from the end of the line - but it is not as slow as when I’m typing at the very end of the line.
Norman - if it would help I’m happy to get profiles of various scenarios… typing at the end of the line, in the middle, connected to an external (huge) monitor, only on the laptop screen, connected to wall power, running on battery, etc.
Extra samples with a description of the scenario would be useful to see if / what common things are in the samples
Like I said the one you posted is radically different than the others posted
Plus a full system profile would be good.
I have some … interesting things to report… is it better that I put them in the bug in feedback where we’ve been tracking this or better to report them here?
Bug report.
I’m in the process of uploading a whole bunch of testing results to https://xojo.com/issue/40564.
Here is what I’ve learned this am:
Cursor position (end of line vs middle of text) does not seem to have a huge effect, but perhaps it is a little faster to not be typing at the end of the line.
Plugins enabled / disabled don’t seem to make any difference.
Autocomplete enabled / disabled don’t seem to make any difference.
Bluetooth keyboard vs. built-in laptop keyboard makes no difference.
Retina vs. non-retina display makes no difference.
The behavior is still present in 10.11.1 (upgraded just yesterday)
If I turn on speech recognition in the OS, the text is entered VERY quickly by the speech engine, even when autocomplete is turned on… and you can see it trying to autocomplete things as I’m speaking. I made a screencast of this.
So, my money is on something going on in the event handlers for keystrokes… because getting text into the editor in ways other than using a keyboard seem to be very fast.
This is basically the conclusion that Norman and I came to.
Unlike most of the rest of the samples THESE point to a specific cause in every sample
So hopefully fixing that will have positive effect for everyone else
It’s a start 
That’s weird because on my Mac (10.9.5) it is entirely related to Autocomplete. When it is turned on, I can get up to 20-30 characters still in the buffer when I quit typing. With Autocomplete off, I can’t get more than 1 character behind no matter how fast I type in even random characters.
How does it behave when you click on the TextField in the Find pane and type? That works fine for me, seems like you would see it there if it were keyboard related.
Not necessarily
True, but it might provide clues to the source of the problem if it works fine there.