I would like to add that checking all those files on every transformation
is even much more expensive on OS390 ( IO, opening and closing is really
expensive on OS390). According to some measurements It could result in 100
? 500% performance degradation.
Igor Hersht
XSLT Development
IBM Canada Ltd., 8200 Warden Avenue, Markham, Ontario L6G 1C7
Office D2-260, Phone (905)413-3240 ; FAX (905)413-4839
Henry
Zongaro/Toronto/I To: [EMAIL PROTECTED]
[EMAIL PROTECTED] cc:
Subject: Support for plugging in
alternative DTM
11/27/2003 10:55 implementations in XSLTC
AM
Please respond to
xalan-dev
Hello,
Today, Xalan-Java Interpretive uses the
org.apache.xml.dtm.DTMManager.getInstance() method to create a DTMManager
object for a transformation. That method uses the
ObjectFactory.createObject mechanism to create an instance of a
DTMManager. That will look up the name of the selected DTMManager service
provider by:
- checking the org.apache.xml.dtm.DTMManager system property;
- checking for an org.apache.xml.dtm.DTMManager property in
the $JAVA_HOME/lib/xalan.properties file;
- checking for a META-INF/services/org.apache.xml.dtm.DTMManager
file.
XSLTC uses the
org.apache.xalan.xsltc.dom.XSLTCDTMManager.newInstance() method to create
a DTMManager for a transformation. That method contains a hard-coded
reference to the XSLTCDTMManager constructor.
The advantage of Xalan-Java Interpretive's approach to creating a
DTMManager is that it is highly configurable. The disadvantage is that
checking all those properties and files on every transformation is a very
expensive process. I'd like to enable the same kind of run-time
flexibility in selecting a DTMManager to XSLTC, but I found that using the
same ObjectFactory.createObject mechanism on every transformation resulted
in about a 10-20% performance degradation for small transformations,
unless I explicitly set the system property. That's clearly unacceptable.
I've been toying with an alternative that would allow for some
configurability in XSLTC, without the performance degradation. I'd like
feedback from the mailing list on that method first, since we'd probably
want to follow the same pattern in future. Here it is:
- When an XSLTC TransformerFactory is created, it would check the value of
a new XSLTCDTMManager property (first checking for a system property, then
in the xalan.properties file, and then in a META-INF/services file) and
save that value in the TransformerFactory object. If no such property is
available, the default would be the current XSLTCDTMManager.
- All Transformer objects created from a TransformerFactory would use the
value of the XSLTCDTMManager property that was in effect when the
TransformerFactory was created. Subsequent changes made to the system
property would have no effect on that TransformerFactory or the
Transformers created from it - it would only affect any TransformerFactory
objects subsequently created. Similarly, if the context class loader made
available a different META-INF/services file, that change would have no
effect on a TransformerFactory that was created with respect to an earlier
version of the META-INF/services file.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:[EMAIL PROTECTED]
