slow response time when editing long documents

SyntaxEditor for WPF Forum

Posted 9 years ago by tal
Version: 15.1.0623
Platform: .NET 4.5
Environment: Windows 8 (64-bit)
Avatar

Hey,

We would like to report two issues that we have encountered:

  • While stress testing our editor we found that using the WordHighlightTagger slowed down the editor to a point which is impossible to work with (1-2 seconds delay between a keystroke and a letter appearing even when using the original example in the Sample Browser itself). We found that the GetCurrentWordText is the most expensive (using the VS profiling). The document which we tested on it was approximately 300,000 characters long.
  • On that same document we also used the editor.ActiveView.GetReader() (in the editor’s DocumentTextChanged event if that’s important to specify) and found out that the ReadTokenReverse function took an extremely long time to complete.

In a few other places, reader.Token also took quite some time to execute.

Do you know why it might happen? What options do we have if we need to use the editor with such long documents?

In thanks,
Asaf & Tal

Comments (3)

Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 9 years ago by tal
Avatar

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!

Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

The latest build of this product (v24.1.1) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.