slow response time when editing long documents

Hello,

1) I am not seeing this slowdown.  When I pasted a 10MB file in the Sample Browser's Highlight Word QuickStart, I was able to type without noticable delay and highlights showed fast.  If you are using an advanced language, are you sure you have the ambient parse request dispatcher started?  If you don't and the language has a parser, then you might be running parsing operations in the main UI thread, which would lead to such a typing lag.

2) Tokens in the WPF version are not stored and everything is virtualized to reduce memory usage.  Thus, as you use a reader to enumerate through tokens, it is jumping back a bit, using the lexer the scan a small section of text for tokens, and then returning the next token to you.  Subsequent calls to the same reader keep returning tokens from the token set that was scanned until the end of it was reached, and then the process repeats where it lexes another small section of text for a new token set.  This generally runs pretty fast as long as you aren't doing massive scanning around.  If you do need to do large extensive scanning, it would be better done in a worker thread, such as in an IParser service.  Otherwise, you might be blocking the UI thread.

Hey,

We used the example of the HighlightWordQuickStart without changing it, you can replicate the problem with a single very long string token (something like double quote, ‘asd’ * 100000, double quote, new line) and then anything after that is delayed...

*We have set up the ambient parser (as described in the manual and in use in the Sample Brower source code).

Regarding the Token, using the same long document, on every document text change we only wish to know the current Token’s key (from where the selection is). So we are creating a reader on every keystroke and reading its Token property which under profiling took a significant time for each call… (Since we wish to affect the text change (according to the token key) we have to do it in the same thread.)

Thanks again for the fast reply!

Hello,

Ok, the problem there is that SyntaxEditor doesn't currently handle extremely long lines well since every time it renders a line, it has to reformat the entire line.  So in this scenario, the word highlight isn't slow itself, it's just triggering a new layout but the layout is taking a while since you have very long lines.

I would recommend not using such long lines and you should see performance improve dramatically.  For instance you could have the same number of document characters but distributed over multiple lines and it will work fast.