The variables
154 ShortComponentRaster shortRaster;
155 IntegerComponentRaster intRaster;
156 ByteComponentRaster byteRaster;
are each used only in a localised few lines of code,
can we move them to the block where they are used so
that their scope is limited to that ? I don't know for a fact
but I can imagine that the VM can then skip allocating stack for them
until you enter that block which actually needs them.
As you note,this takes into account old and new builds in the makefile
changes
Have you tested both ?
And unless you are 100% confident in this [minimal] change
you should get sign off from the build group as they've recently requested.
You should add "noreg-perf" as a label in the JIRA
-phil.
On 1/9/2013 4:25 AM, Andrew Brygin wrote:
Hello Jennifer and Phil,
could you please review a fix for CR 8005530?
CR: http://bugs.sun.com/view_bug.do?bug_id=8005530
Webrev:http://cr.openjdk.java.net/~bae/8005530/webrev.00/
This fix improves performance of ColorConvertOp.filter()
operation in case of lcms. The fix can be divided into
three separate changes:
* provide support for custom component images in
LCMSImageLayout.
This change affects the case of conversion to default
destination.
* provide a way to process whole image, instead of
scan-by-scan processing, if both source and
destination images do not contain padding samples
(i.e. next scan starts immediately after previous).
* increase optimization level for lcms library from
LOW to HIGHEST. This change affects both new and
standard build systems.
A benchmark comparison below illustrates the increase
of performance:
Options common across all tests:
testname=cmm.colorconv.ccop.op_img
cmm.colorconv.ccop.ccopOptions.srcType=BYTE_3BYTE_BGR
cmm.colorconv.ccop.ccopOptions.content=photo
cmm.opts.profiles=1001
cmm.colorconv.ccop.ccopOptions.dstType=BYTE_3BYTE_BGR,cmm.colorconv.ccop.ccopOptions.size=250:
OpenJDK Baseline: 0.152008134 (var=1.02%) (100.0%)
*************************************|
*************************************|
*************************************|
OpenJDK Fix: 0.245116358 (var=2.0%) (161.25%)
*************************************|**********************
*************************************|**********************
*************************************|*********************
cmm.colorconv.ccop.ccopOptions.dstType=BYTE_3BYTE_BGR,cmm.colorconv.ccop.ccopOptions.size=4000:
OpenJDK Baseline: 0.914826498 (var=0.41%) (100.0%)
***************************|
***************************|
***************************|
OpenJDK Fix: 0.001310043 (var=2.24%) (221.48%)
***************************|********************************
***************************|********************************
***************************|********************************
cmm.colorconv.ccop.ccopOptions.dstType=COMPATIBLE_DST,cmm.colorconv.ccop.ccopOptions.size=250:
OpenJDK Baseline: 0.060737151 (var=1.57%) (100.0%)
***************|
***************|
***************|
OpenJDK Fix: 0.242736486 (var=1.53%) (399.65%)
***************|*******************************************
***************|********************************************
***************|********************************************
cmm.colorconv.ccop.ccopOptions.dstType=COMPATIBLE_DST,cmm.colorconv.ccop.ccopOptions.size=4000:
OpenJDK Baseline: 0.559251559 (var=0.7%) (100.0%)
*******|
*******|
*******|
OpenJDK Fix: 0.001306904 (var=1.05%) (838.16%)
*******|***************************************************
*******|****************************************************
*******|****************************************************
Summary:
OpenJDK Baseline:
Number of tests: 4
Overall average: 0.053373173444166644
Best spread: 0.41% variance
Worst spread: 1.57% variance
(Basis for results comparison)
OpenJDK Fix:
Number of tests: 4
Overall average: 0.12261744826137347
Best spread: 1.05% variance
Worst spread: 2.24% variance
Comparison to basis:
Best result: 838.16% of basis
Worst result: 161.25% of basis
Number of wins: 4
Number of ties: 0
Number of losses: 0
Thanks,
Andrew
