Thanks, Brian. Will do. Seems that the core issue is probably due to having to maintain two separate representations of the XML content (DOM and DTM) versus a single or auto-synchronized representation inside MSXML and/or .NET (though, not being open source, I'm merely opining on the possibilities).
In the interim, we're trying all possible permutations of the CachedXPathAPI to see what we can do. I suppose the main question comes down to "what types of changes to the DOM would constitute invalidation of the XPathContext"? Our application is often changing Element values (child text nodes) and appending/removing nodes. It is difficult to synchronize this with invalidation of the CachedXPathAPI object, though, if necessary, we'll try... - Rick -----Original Message----- From: Brian Minchau [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 15, 2004 9:58 AM To: [EMAIL PROTECTED] Subject: Re: The ever popular Xpath peformance questions.. Rick, performance is one of those fuzzy areas. We never know what can be done. I'd rather not just let this sit as a 10X-20X degredation over .NET. Please open an issue in JIRA (not bugzilla anymore) http://nagoya.apache.org/jira/ The project is XalanJ2, the issue type is probably Improvement. I see that there are three bugs that you opened in bugzilla that were migrated from bugzilla to JIRA, but not this one. Your JIRA ID should be the same as your old bugzilla ID, although the password is new. You may need to click the "forgot password" to get the new password mailed to you. Please attach relevant XML/XSL and Java code. ---------- Brian Minchau XSLT Development, IBM Toronto e-mail: [EMAIL PROTECTED] "Rick Bullotta" <[EMAIL PROTECTED] ghthammer.com> To <[EMAIL PROTECTED]> 12/15/2004 09:06 cc AM Subject The ever popular Xpath peformance Please respond to questions.. xalan-dev After weeks of scouring the newsgroups and Googling, and much experimentation, we remain absolutely perplexed as to how to get better Xpath performance from Xalan (mostly in selectSingleNode and selectNodeList operations). In our case, the source will always be a Xerces DOM. We're experiencing a roughly 10X-20X degradation in performance relative to comparable code using the Microsoft Xpath evaluation functions in .NET. We're about to consider trying Dom4J or JDOM just to see if we can get some better performance, but we'd hate to give up now. We have tried CachedXPathAPI, but its usage is quite unclear (and how the DOM/DTM gets cached is still unclear). Low level API's are certainly an option, but we're in the dark as to appropriate usage. Consider this a plea for help and guidance! Happy holidays to all, Rick Bullotta CTO Lighthammer Software (http://www.lighthammer.com) --------------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
