Indent command becomes extremly slow

SyntaxEditor for Windows Forms Forum

Posted 11 years ago by BLANC Stéphane - Staubli Robotics Suite Product Manager, STAUBLI
Version: 4.0.0281
Platform: .NET 3.5
Environment: Windows XP (32-bit)
Avatar
Hi,

I'm having problem with the indent command.
In fact, it becomes extremely slow if you have more than 1000 lines in your file.
It seems that the TextChanged event is fired for each line each time you press the TAB key.

To reproduce it :
* open your sample application : ".NET Language Reflexion with external reference"
* enter 5000 lines of code
* Select All
* Press TAB or Shift + TAB
... it takes more than 10 seconds to increase indentation

Thanks for your help

Stéphane

Remark : In the help file - "Large file handling" section,
you suggest to "Alternatively, make your changes in a StringBuilder and then set the StringBuilder's text back to the document." to prevent too many events but it's not possible because if you replace the entire document you lose all the line indicators...

[Modified at 05/04/2009 09:45 AM]

Comments (5)

Posted 11 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Stéphane,

Yes that is something we are aware of and have been working on improving. There are 5000 individual changes in the example you gave, which is the reason why it takes so long.

That being said, in the new text/parsing framework we've been prototyping with our WPF version, this is something we've worked on. We can indent 5000+ lines in about 1.2 seconds in the current WPF alpha build. That's even much faster than VS 2008 can do, for a C# doc at least.

Down the road we hope to port this text/parsing framework to a future SyntaxEditor for WinForms version, but it has some major design changes and still needs work to bring the feature set up to what is currently in SE4. The speed increase for your particular issue are part of those major design changes we've made to help performance.

You are right, that tip in the docs will blow away existing indicators. Our indent code used to do that however users complained, which is why we switched it to individual transactions instead like it is now.


Actipro Software Support

Posted 11 years ago by BLANC Stéphane - Staubli Robotics Suite Product Manager, STAUBLI
Avatar
Hi and thanks for your answer,

the problem is that in our application we are attached to textChanged event.
I gave you the example with 5000 lines but in our case it takes 10 seconds for 1000 lines.
Further more, it crashes the application if you press Ctrl+Z which is not acceptable for the user.

We do need a solution/patch/workaround to this problem (without waiting/thinking of a migration to WPF !)

I tried to stop the semantic parser, to suspend painting, suspend layout but it has not effect.

We are facing the same problem when we are developing our own FormatTextRange.
Is there a way to prevent the document to raise the event ?
Something like document.raiseTextChanged = false

Thanks for your help

Stéphane

[Modified at 05/05/2009 10:17 AM]
Posted 11 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Stéphane,

I was just mentioning that we have been working on improving speed of multiple replace transactions with the text/parsing framework that we're prototyping with the WPF SyntaxEditor. The WPF version is designed such that the text/parsing framework is in its own .NET 2.0 assembly so that it can be cross platform and be used by WinForms down the road. It has no dependencies on WPF UI. I wouldn't expect you to move to WPF for this, I'm merely indicating that we've made our next gen text/parsing framework so that it can be used in WPF and WinForms. The part that will take time is altering the WinForms UI code to work with it and have the same features and more that are in SyntaxEditor 4.0.

Part of the updated design I'm talking about is that we have altered things so that you can batch up multiple replace operations into a single "text change". This means that a single text changed event can fire for 1000 replace operations, which sounds like what you want. But again the downside is that this is not yet available for WinForms and it has taken a major effort to develop this new model since there are a lot of other new enhancements that go along with it.

There isn't a way to suspend the text changed event right now, however if some code you have in response to it is slowing everything down, you could simply add a flag on your end as to whether to do any processing in that event or not. Thus you'd be able to suspend it from your side.


Actipro Software Support

Posted 11 years ago by BLANC Stéphane - Staubli Robotics Suite Product Manager, STAUBLI
Avatar
Hi Bill,

Even if we remove our code it's extremely slow and the CTRL+Z crashes the application.
As far as I understand we have no possibility to implement a workaround in our code using the current version and you don't plan to correct it.

Eight month ago I submitted a bug regarding the lines indicators and I have no news (http://www.actiprosoftware.com/Support/Forums/ViewForumTopic.aspx?ForumTopicID=3246)

Shall I concluded that SyntaxEditor is no more supported ?

Anyway, I repeat it again, but we must imperatively find a solution to prevent this bug (even if it requires work on our side)

Thanks for your help

Stéphane
Posted 11 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Stéphane,

If you email over a simple sample project we can take a look at it and see if we have any tips for you. However as mentioned, due to how v4.0 works, it can be slow with very large amounts of edits. Still even with that Ctrl+Z should not crash anything.

We have identified performance issues like what you are describing and that is specifically why we have been working the past number of months on making an improved text/parsing framework that will be cross-platform (WPF, WinForms, etc.). The next gen framework is geared to be fast and make speed improvements in a number of areas. So I would definitely not say SyntaxEditor isn't supported. Things like this issue are exactly why we're working on the next gen framework. However we are prototyping it out with the WPF version simply because there will be breaking changes and we wanted to nail those down first before migrating it into WinForms.

Our support on existing products is a bit slower over the last couple months since as mentioned a couple weeks ago in that other topic, we are under a lot of pressure to get WPF Studio 5.0 out. The main holdup there is completing SyntaxEditor for WPF's public beta. We estimate 2-3 weeks of work left. And as indicated in that other post, we'll be able to look more at existing product enhancements after that is released, so please check back with us then.


Actipro Software Support

The latest build of this product (v2020.1 build 0400) was released 24 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.