JDK-6922044 : XSLTC performance regression in 1.6.0_18
  • Type: Bug
  • Component: xml
  • Sub-Component: javax.xml.transform
  • Affected Version: 6,6u18
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8,windows_xp
  • CPU: x86
  • Submitted: 2010-02-02
  • Updated: 2012-04-25
  • Resolved: 2010-02-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7
1.4.0 h1200Fixed 6u21-revFixed 7Fixed
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 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.
05-02-2010
EVALUATION This is due to the integration of CR6513892. While the original change was fine, the FileOutputStream needs to be wrapped with a BufferedOutputStream.
05-02-2010