United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6922044 XSLTC performance regression in 1.6.0_18
JDK-6922044 : XSLTC performance regression in 1.6.0_18

Details
Type:
Bug
Submit Date:
2010-02-02
Status:
Closed
Updated Date:
2012-04-25
Project Name:
JDK
Resolved Date:
2010-02-05
Component:
xml
OS:
solaris_8,windows_xp
Sub-Component:
javax.xml.transform
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6,6u18
Fixed Versions:
1.4.0 (h1200)

Related Reports
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7600]

A DESCRIPTION OF THE PROBLEM :
A change to com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.java in 1.6.0_18 appears to cause a performance regression when the output encoding is US-ASCII.

I noticed this when running ant junitreport tasks with output on file servers -- the time to process junit output jumped from a few seconds to tens of minutes. I tracked it down to com.sun.org.apache.xml.internal.serializer.WriterToASCI being initialized with a non-buffered FileOutputStream.

As far as I can tell the source of this problem is a change on line 554 of AbstractTranslet.java:

	    factory.setWriter(new FileWriter(filename, append));

became

	    factory.setOutputStream(new FileOutputStream(filename, append));

This change from a Writer to an OutputStream triggers com.sun.org.apache.xml.internal.serializer.ToStream to create a WriterToAsci on top of the unbuffered stream.

Subsequent writes of one byte at a time to this unbuffered stream cause lots of network traffic, but not much progress ;-)


REPRODUCIBILITY :
This bug can be reproduced always.

Release Regression From : 6u17
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

                                    

Comments
EVALUATION

This is due to the integration of CR6513892. While the original change was fine, the FileOutputStream needs to be wrapped with a BufferedOutputStream.
                                     
2010-02-05
EVALUATION

Fixed. Customer confirmed that the change fixed the problem. A junitreport test on my local machine showed significant improvement: transform time went from about 27800ms down to about 1700ms.
                                     
2010-02-05



Hardware and Software, Engineered to Work Together