Hi ChengLin, Saxon9 is supporting XSLT1.0 as well. Have you tried your stylesheets as well with Saxon? Please note that Saxon is a little more restrictive about errors you made, you might have to fix a few things, as I did for the XSLT filters already in OOo.
PS: Take first Java start-up time into account during your tests.. Kind regards, Svante ChengLin wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
