Bug 63681 - Perfomance regression in ContentWidthCache#contentWidth()
Summary: Perfomance regression in ContentWidthCache#contentWidth()
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P2 major (vote)
Target Milestone: ---   Edit
Assignee: Felipe Heidrich CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks: 60703
  Show dependency tree
 
Reported: 2004-05-24 10:10 EDT by Christof Marti CLA
Modified: 2005-04-22 12:11 EDT (History)
5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christof Marti CLA 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 CLA 2004-05-25 15:42:37 EDT 
FH and SSQ to investigate.
Comment 2 Felipe Heidrich CLA 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 CLA 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 CLA 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 CLA 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 CLA 2005-04-22 09:21:03 EDT 
So should this PR be closed?
Comment 7 Felipe Heidrich CLA 2005-04-22 12:11:20 EDT 
Closing.