I'd certainly like to see this case so that I can try and
identify what was going wrong.
When you say the xsd:includes were redundant, do you mean
that modules were being included that weren't needed at all, or that modules
were being included more than once when once would have been
just tried using Saxonica with a fairly complicated schema
required about 5 minutes to parse in Saxonica
(same time if performed
as an xsl:import-schema or as a Java addSchema in
Could this be due to redundant includes? Any pointers on
how to debug
think the most likely cause of such poor performance is a very
content model for a complex type: the algorithms for building the
state machine are worse than linear (I forget the details) in
the size of the grammar.
However, that's a guess.
There's always a possibility of a performance bug
that's due to
something quite trivial that can be easily fixed. So the best
thing is to
send me the source and let me study what's going on internally.
also seen poor performance from the Java VM in compiling complex
expressions - however, I haven't seen that recently; it may have
performance bug in an early version of JDK 1.4.
did try switching from JRE 1.4 to JRE 1.5 and noticed about
improvement. Still, parsing was taking a number of
Then I attacked the "xs:includes" in the schema files.
This schema is an
FPML-based model with about 40 different files that are
made to be valid
either as simple models or as more complex and combined
The upshot is that many files are included redundantly.
So I changed the model to a flat, top-level inclusion of files.
nested includes. The Schema parsing time dropped from several
(at constant memory profile, by the way) to 2 seconds. This
is a pretty
I can send along the
original pathological case in case that it's interesting.
I'm curious why
redundant includes would produce such an exponential
increase in parsing
time, but mostly I'm happy that the non-pathological
case is so