Hi Svante, Thank you very much for your concerns about UOF stylesheet. We're trying to improve it. Optimizing XSLT is one step, I think we should take more steps for better performance. I've tested Xalan-C++ and it's almost 3 times faster than Xalan-Java. So I hope to exchange in OOo XML filter. But I don't know how much workload needed and wonder if there'll be many risks. Could you give me some advice on this? Should we give up Xalan-C++ and wait for Saxon and change to XSLT2.0?
Thanks and regards! ------------------ ChengLin 2008-07-09 ------------------------------------------------------------- 发件人：Svante Schubert<[EMAIL PROTECTED]> 发送日期：2008-07-09 21:23:25 收件人：dev<[email protected]> 抄送： 主题：Re: [xml-dev] FYI: Enhancing XSLT processing in OOo 3 - exchangingXerces/Xalanduo with Saxon processor 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]
