Comment 1 Amy Wu 2006-09-26 17:55:18 EDT

Created attachment 50963 [details]
sample css file

Comment 2 David Williams 2006-10-18 00:52:06 EDT

Interesting ... assigning to you Amy to see if you can narrow it down. 

Comment 3 Amy Wu 2008-10-27 04:22:15 EDT

reassigning to inbox

Comment 4 Michael Spector 2008-12-23 03:21:56 EST

Created attachment 121112 [details]
Misusage of assertion in a getter method

Comment 5 Michael Spector 2008-12-23 03:28:21 EST

1. First of all, there's a simple bottleneck: call to org.eclipse.wst.sse.core.internal.util.Assert in a getter(1) method, which is called about 60,000 times during typing of 10 characters in a CSS editor.

2. Another (big) problem is in StructuredPresentationReconciler: it seems like org.eclipse.jface.text.TextViewer.modelStyleRange2WidgetStyleRange(StyleRange) is a very expensive operation, which is invoked by the textChanged() callback method. I don't know yet how it can be fixed, but I'll try to understand what can be done in order to improve performance in this place.

Comment 6 Remy Suen 2008-12-23 08:47:17 EST

(In reply to comment #4)
> Created an attachment (id=121112) [details]
> Misusage of assertion in a getter method

Since the line tracker is only ever set once with a non-null input, it seems to me that removing the assertion call there should be safe.

With regards to the text store, perhaps the assertion could be moved to the setter to ensure that it never ends up being null in the getter?

Comment 7 Michael Spector 2008-12-24 04:51:19 EST

Created attachment 121205 [details]
Misusage of assertion in a getter method

Comment 8 Nitin Dahyabhai 2008-12-24 11:38:59 EST

I'll give you that while 259547 might cause breaking changes for the standard document implementation, our implementation's use of private setters and getters lets us move the assertion calls into the setters.  However, the StructuredPresentationReconciler mentioned in comment 5 would not be the original cause--this bug report predates its introduction.

Comment 9 David Carver 2009-03-19 21:09:56 EDT

Tentatively marking as future, as it appears more investigation is needed for the actual cause.   I suspect this is a SSE related issue as the same performance issue happens in HTML, XML, XSL, XSD, and other editors.

Michael, I know some recent changes to the SSE editor in determining character position have gone into place, can you verify if this is still happening in 3.1M6 of WST?

Comment 10 Michael Spector 2009-03-20 02:10:12 EDT

(In reply to comment #9)
> Tentatively marking as future, as it appears more investigation is needed for
> the actual cause.   I suspect this is a SSE related issue as the same
> performance issue happens in HTML, XML, XSL, XSD, and other editors.
> 
> Michael, I know some recent changes to the SSE editor in determining character
> position have gone into place, can you verify if this is still happening in
> 3.1M6 of WST?
> 

Editing of CSS documents is much faster in 3.1M6! I think this bug can be closed now.

Comment 11 gossi 2009-09-09 21:05:33 EDT

Created attachment 146826 [details]
Wordpress CSS file

Comment 12 gossi 2009-09-09 21:16:49 EDT

I'm working with the final 3.1 (Galileo Release). And there are still performance problems.

Instead of the initial creator of this bug, I neither have folding enabled nor do I have the properties view open. Instead I do have the Outline view open and the sort modality is enabled.

The typing just got slow when I'm altering either a statement or a property. I've added the Wordpress CSS Classic file I was editing, it's "huge" enough to let this happen. After typing my letters there (means finished with my fingers), I can watch my letters appear.

But it gets even more worse. Putting around a comment on a css-property is messy. Adding /* in front of a prop invokes the outline to be filtered, cause everything after that comment is being ignored. I can watch the nodes made hidden rsp. visible.

Comment 13 Roy Ganor 2009-09-10 01:35:45 EDT

This is a hotbug request as described at http://wiki.eclipse.org/WTP/Hotbug_Policy
The main reason for this request if loss of usability and blocking of testing.

When working with the CSS editor it is frozen ost of the time, this happens from two main reasons:

1. The replaceText() method is not optimized - when adding or removing text the way to update the StructuredDocumentRegions and the Nodes of the editor should be improved.
2. The folding method is not optimized - this functionality can be eliminated easily so this is less "critical", still will be nice if we resolve this as well.

Comment 14 Nitin Dahyabhai 2009-09-10 13:55:59 EDT

For which release is this requested?  Our final 3.1.1 build was intended to be this morning.

Comment 15 Nitin Dahyabhai 2009-12-16 14:28:50 EST

Bug 281380 worked on separately to address overall folding-enabled performance.

Comment 16 Ian Tewksbury 2010-01-18 13:37:05 EST

(In reply to comment #15)
> Bug 281380 worked on separately to address overall folding-enabled performance.

As per the work done in Bug 281380 this no longer seems to be an issue in 3.2

Comment 17 David Williams 2010-01-27 22:20:24 EST

Given the comments, let's count this as fixed and a duplicate of bug 281380. 

If there are other issues or scenarios, please open new bugs with test cases. 

Thanks everyone.

*** This bug has been marked as a duplicate of bug 281380 ***