[
https://issues.apache.org/jira/browse/XERCESJ-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874510#action_12874510
]
Chris Simmons commented on XERCESJ-1449:
----------------------------------------
Actually the slowness seems to scale with the depth of the stack too. If I add
a bit of recursion to add 50 layers to the stack like this
private static void runTests(final XML11Configuration config) throws
IOException {
runTests(config, 50);
}
private static void runTests(final XML11Configuration config, final int
depth) throws IOException {
if (depth == 0) {
process(config, "string");
process(config, "dateTime");
process(config, "dateOrDateTime"); // Union (date, dateTime)
process(config, "dateTimeOrDate"); // Union (dateTime, date)
}
else {
runTests(config, depth - 1);
}
}
then it takes more like 8 times longer. This is more like the performance I've
seen in real life as the stack is likely to be deeper than in my original
sample.
> Validation of schema type unions are relatively slow due to use of exceptions.
> ------------------------------------------------------------------------------
>
> Key: XERCESJ-1449
> URL: https://issues.apache.org/jira/browse/XERCESJ-1449
> Project: Xerces2-J
> Issue Type: Improvement
> Components: XML Schema 1.0 Datatypes
> Reporter: Chris Simmons
> Attachments: XercesUnionPerformance.zip
>
>
> I'll shortly attach some example code which shows that validating
> 2010-01-01T00:00:00.000Z
> against the union (date, dateTime) is slower by a factor of three than
> validating against (dateTime, date).
> This appears to be because if validation fails against the first member of
> the union then an exception is thrown.
> It would therefor be quicker to change the simple type validation to allow an
> error handler of some sort to be passed in so that union types will not have
> to use exception handling when validating.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
