Document performance improvements

SyntaxEditor for Windows Forms Forum

Posted 12 years ago by Kasper
Version: 4.0.0262
Avatar
Hi,

In my application, I'm using the Document of SyntaxEditor to do some parsing for me. Since it's constructed in such a brilliant way, this makes it very easy to use the Document class to your advantage, when parsing files - I'm loving it! :)

However, for a feature that I'm creating, I need really fast parsings. I have debugged my code, and I can see that the line where I set the Text property of the Document takes at least 100 milliseconds, even for pretty small documents. I have already disabled Outlining, LineModificationMarking and SemanticParsing, as described in the documentation. I have not disabled LexicalParsing, since I'm using the tokens to provide the data I need. Is there anything else I can do? Is there another way of setting the text of the document which will make it any faster? I noticed that the difference between setting a 50 line document and a 900 line document is not that big, so I thought that there may be a smarter way. Any performance tips for me? :)

Comments (3)

Posted 12 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Unfortunately not, it sounds like you are already doing everything that is recommended. So perhaps there is just some general overhead that is taking a little time since you said small and larger documents don't have that much time difference.


Actipro Software Support

Posted 12 years ago by Ernesto Obregon
Avatar
An improvement I noticed came when I stream lined my error handling. I am using VB.NET and noticed that Try...Catch..Finally statements were consuming a lot of overhead. These should not be used except in cases where errors occur. Try to avoid nested error checking code from functions, subs, classes, ect, where you might be calling a sub with error checking already in place then call another sub or function that also has error checking code.

Basically stream lining error checking can help.
thanks
Posted 12 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Ernesto,

Actually we barely use any try...catch in our code at all. The reason is that if there are problems, we want to funnel the exceptions up to the UI so that problems may be identified and handled properly. If we would catch exceptions then there could be a major flaw in our code that we'd never know about.

We use some try...catches in our .NET Languages Add-on code when doing initial reflection on an assembly (only happens at first load) but other than that, there really isn't any use of those.

It's a good tip to know in general though, thanks!


Actipro Software Support

The latest build of this product (v2018.1 build 0341) was released 7 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.