ChengLin wrote:
Good news!
Why don't we change to C++(.NET) Saxon so as to run without JRE and probably
faster?
BTW, I hope to exchange the Xalan-Java with the Xalan-C++ to improve XSLT
performance. Is there any already known problem?
Hi ChengLin,
The .NET version of Saxon is not completely written in c# for .NET,
moreover it is based on the same Java sources, but compiled to DLLs
using IKVM providing a OpenJDK library and Java virtual machine for
.NET. I am not aware of performance gain/loss, but I assume it was meant
for customers in a pure .NET environment or any abstract reason, than
for performance reasons.
Saxon will exchange the Xalan-Java to provide XSLT2 features, which
Xalan-C++ has neither.
And remember - as I told you before - you can loose a lot of performance
in XSLT, when you do too large queries, e.g.
Matching "//office:body" will search the whole XML document tree for the
unique element office:body and will even continue, when the first (and
only) office:body is being found. By doing this you will certainly loose
some performance.
Instead you better access more explicitly "/*/office:body".
I use a wildcard for the root element to make this filter usable as XSLT
filter in the office, which receives a flat XML with office:document or
on a ODF package, which uses an office:document-content as root element.
You might wonder why I mention this query performance case, but I
recently realized that "//office:body" is being used half a dozen times
in the UOF text filter.
You see, still room for performance improvement on the stylesheets.. ;-)
Kind regards,
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
