https://bz.apache.org/bugzilla/show_bug.cgi?id=61875
--- Comment #8 from Jeremy Boynes <jboy...@apache.org> ---
(In reply to Matthew Broadhead from comment #7)
> i stepped through ForEachTagTest.java
>
> line 140 if (tag.doStartTag() == IterationTag.EVAL_BODY_INCLUDE) {
> seems to take a long time
>
> line 142 result = dot.evaluate(tag.getCurrent());
> takes virtually no time but the iterations seem to add up to a lot of time
> in total
>
> i don't really understand the ins and outs but it seems like every element
> has been split up and stored separately instead of being stored as an xml
> structure. so the xml search tools don't work very well it is like loading
> a separate document for each search.
>
> is there any way to access the low level dtm stuff through the javax.xml.*?
The xpath engine in Xalan was designed to allow repeated fast evaluation of
xpath expressions during XSLT processing. It does that by taking an upfront hit
to build a DTM model of the document being processed, a model that is then
reused each time an xpath expression needs to be evaluated.
The current implementation mirrors that in the context of JSTL. It constructs
the model once in ForEachTag#doStartTag then reuses it when evaluating the
xpath expressions inside the loop just like the XSLT engine does. It takes
advantage of a portion of the JSTL spec that allows other implementations of
XML context than a DOM.
When using JAXP it is limited by the standard API to using DOM objects as
context. That means every time an XPath expression is evaluated, the engine has
to recreate the DTM model before it can evaluate the expression. It does that
starting from the root had has to work over the N-1 preceding nodes, hence the
O(N^2) behaviour.
In theory, the JAXP XPath API allows different "object models" to be selected.
See
https://docs.oracle.com/javase/1.5.0/docs/api/javax/xml/xpath/XPathFactory.html#newInstance(java.lang.String)
so there may be a way to use DTM with the default JAXP implementation (which in
Oracle's and OpenJDK is a shaded version of Xalan which would support DTM). The
downside of this would be if there were other JDKs that did not support DTM.
I think Glassfish ended up simply shading Xalan and bundling it with their
implementation. We could do that as well, perhaps adding a "bundle" jar that
includes all the tags along with a shaded version of Xalan that was intended to
used by containers rather than applications.
So perhaps multiple packagings:
- pure JAXP, smaller but with a known performance issue with XML processing
- Xalan bundled, larger but with no performance issue
- unbundled, so application users can choose what tags and dependencies they
include
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
