[
https://issues.apache.org/jira/browse/JXPATH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028113#comment-15028113
]
Michele Vivoda commented on JXPATH-183:
---------------------------------------
Hi, I think this is the source of the problem, from
{{ValueUtils.getIndexedPropertyLength()}}, {{UNKNOWN_LENGTH_MAX_COUNT}} is
{{16000}}
{noformat}
for (int i = 0; i < UNKNOWN_LENGTH_MAX_COUNT; i++) {
try {
readMethod.invoke(object, new Integer(i));
}
catch (Throwable t) {
return i;
}
}
{noformat}
The method javadoc says it
bq. guess the length of the collection by calling the indexed get method
repeatedly. The method is supposed to throw an exception if the index is out
of bounds
Not sure why is done in this way, however this method is called only for
properties that are described by {{java.beans.IndexedPropertyDescriptor}}, this
is the case for {{XMLGregorianCalendar.getTimeZone(int)}}, then I don't know
if/how your XPath gets there, can you provide your XPath expression ?
> XMLGregorianCalendar existence adding a lot of performance penalty
> ------------------------------------------------------------------
>
> Key: JXPATH-183
> URL: https://issues.apache.org/jira/browse/JXPATH-183
> Project: Commons JXPath
> Issue Type: Improvement
> Affects Versions: 1.3
> Environment: Windows 7, Amazon Unix, Weblogic
> Reporter: Ganna Shmatova
> Labels: performance
>
> We're using JXPath to parse some input from a client. When they give us a
> valid date it gets transformed from a SOAP message into Java objects. When
> this happens JXPath queries suddenly take 1-8 seconds more (depending on
> system -- the optimized system it's 1 second, dev & test machines it's 8).
> Kicker is, we don't even look for this field. Just its existence does it.
> (we've quickfixed to omit the xml tags before the string is parsed into Java
> for now)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
