Bug 63681

Summary:	Perfomance regression in ContentWidthCache#contentWidth()
Product:	[Eclipse Project] Platform	Reporter:	Christof Marti <christof_marti>
Component:	SWT	Assignee:	Felipe Heidrich <eclipse.felipe>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	major
Priority:	P2	CC:	billy.biggs, Kevin_Haaland, Mike_Wilson, Silenio_Quarti, Tod_Creasey
Version:	3.0	Keywords:	performance
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:
Bug Blocks:	60703

Description Christof Marti

2004-05-24 10:10:55 EDT

As documented in bug 60703 comment 13, ContentWidthCache#contentWidth() shows a
serious regression (comparing 3.0M9 to 2.1.3) when opening a Java editor:

Results (from one average run each):

Scenario 1:
(invocation count in parenthesis)
                                         2.1.3            3.0M9       ratio
WorkbenchPage#openEditor()         4005ms (10)      6088ms (10)      152.0%
ContentWidthCache#contentWidth()     80ms (340)     1001ms (310)    1251.3%
ratio                                2.0%            16.4%

Scenario 2:
(invocation count in parenthesis)
                                         2.1.3            3.0M9       ratio
WorkbenchPage#openEditor()         2974ms (10)      3535ms (10)      118.9%
ContentWidthCache#contentWidth()     90ms (340)      250ms (310)     277.8%
ratio                                3.0%             7.1%

Comment 1 Steve Northover

2004-05-25 15:42:37 EDT

FH and SSQ to investigate.

Comment 2 Felipe Heidrich

2004-06-14 12:09:39 EDT

We did a lot of investigation here and determined that we could get some of the 
time back if we were to merge the internal StyleItems together (on Windows).  
These items are caused by the operating system and StyleText.  The reason it 
gets faster is that there are less objects and less operating system calls when 
processing each StyleItem.

Too dangerous to make these changes now for 3.0.

Comment 3 Tod Creasey

2005-03-07 11:57:20 EST

Adding my name to the cc list as we are now tracking performance issues more
closely. Please remove the performance keyword if this is not a performance bug.

Comment 4 Mike Wilson

2005-04-21 09:53:27 EDT

In comment #2, you indicate that we could get the time back by merging StyleItems. Are you saying 
that, many more StyleItems are being created in R3.0? If not, this may represent a reasonable 
workaround, but isn't actually a fix for the underlying bug.

Comment 5 Felipe Heidrich

2005-04-21 18:11:17 EDT

McQ, this is not really a regression, see bug88670#2. Now StyledText uses more 
time the first time it needs the line (to measure) and then latter on when it 
needs the line again (to draw) it gets time back.

About comment 2:
Back in 2.1 StyledText would merge similar (same attributes, different range) 
adjacent StyleRange objects. This optimization wasn't really helping after the 
changes we did to use TextLayout. Each line in StyledText is a TextLayout, 
reducing the number of ranges (for example) from 12 to 8 does not really 
affect the performance. The average number of ranges is too small to make any 
change in this area interesting.

Comment 6 Mike Wilson

2005-04-22 09:21:03 EDT

So should this PR be closed?

Comment 7 Felipe Heidrich

2005-04-22 12:11:20 EDT

Closing.