Bug 196191 - Performance Improvement for JPEGFileFormat class initializer
Summary: Performance Improvement for JPEGFileFormat class initializer
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4 M6   Edit
Assignee: Carolyn MacLeod CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2007-07-11 13:01 EDT by Bill Tracey CLA
Modified: 2008-03-26 14:14 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Tracey CLA 2007-07-11 13:01:49 EDT
In profiling startup of one of the applications I support I saw the class initializer for org.eclipse.swt.internal.image.JPEGFileFormat accounted for >2% of instructions executed in the scenario.  This seemed excessive -- upon investigation discovered code of the form: 

static int[] someClassTable; 

static { 
    someClassTable = new int[2048]; 
    for ( int i = 0; i < someClassTable.length; i++ ) { 
        someClassTable[i] = some computation; 
    } 
} 

It turns out the access to the class variable from within the class initializer is quite expensive -- changing the code to store thru a local: 

static { 
    int[] local_ClassTable = new int[2048]; 
    // someClassTable = new int[2048]; 
    for ( int i = 0; i < someClassTable.length; i++ ) { 
        local_ClassTable[i] = some computation; 
    } 
    someClassTable = local_ClassTable; 
} 

Applying this change to initializeBitCountTable(), initializeRGBYCbCrTables()
initializeYCbCrRGBTables() results in an instruction count of approx 0.7 million 
for the JPEGFileFormat class initializer.  Without the change the instruction count is in excess of 120 million. 

I can provide the changed code via email.
Comment 1 Steve Northover CLA 2007-07-18 09:57:41 EDT
We are unlikely to change this without a benchmark.  Do you have one?
Comment 2 Steve Northover CLA 2008-01-18 13:47:52 EST
I looked at the code.  We are initializing a bunch of static tables that are constant.  There are many tables so the result is quite a bit of memory gets allocated.  This may cause a garbage collect.
Comment 3 Steve Northover CLA 2008-02-11 11:59:05 EST
Ok, it seems that accessing a static variable during class initialization must lock the class in case it is being initialized from another thread.  I am amazed that this actually makes a difference but it also doesn't hurt to change the code.

Carolyn, just fix it.
Comment 4 Carolyn MacLeod CLA 2008-02-11 15:13:36 EST
Fixed > 20080211