I've added a patch to #27717 that changes the XML tags to use Xalan's low-level API directly. This addresses: 1) Most of the performance issues with iteration from #27717 2) Support for position() and last() from #22765 and others 3) Support for using the same variable twice from #49578 which basically clears up the open bugs with the XML taglib
On my machine, iterating 100000 items took 1600ms which seems OK. It still increases with n^2 for some reason I have not figured out. On Dec 22, 2010, at 7:47 PM, Jeremy Boynes wrote: > > On Dec 22, 2010, at 1:01 AM, Rex Wang wrote: > >> 2010/12/22 Jeremy Boynes <jboy...@apache.org> >>> >>> The XPath implementation in Oracle's JDK was originally based on Xalan and >>> has the same performance issue. >>> >>> One issue with the JAXP API is that it does not allow context to be passed >>> to the evaluation and so the XPath position() and last() functions can't be >>> supported (at least, I've not figured out how). Now the current >>> implementation does not support them either (see #22765) so this may not be >>> a major issue, but the proprietary APIs in Jaxen and JXPath should enable >>> this (would need to code it to be sure). >>> >>> How about: >>> * define our own API that allows context to be passed >>> * create a context-free wrapper for JAXP and remove the hard dependency on >>> Xalan (solving the optional bundle issue) >>> * create other wrappers for Jaxen and/or JXPath that can use the context >>> We could proceed with a release based on the first two steps alone as >>> there's no regression. >>> >> +0 if the reason of defining our own api is only to resolve #22765, since it >> is not required by spec. > > Reading the last 2 bullets on pp157 it references context position and size > and the only way to access those in XPath would be using the position() and > last() functions. > >> And, the performance issue is not a blocker to you to do release? > > It's been there long enough so no :) > It's more that if a fix requires changes to the dependencies it's user > impacting. > > There are still the two issues with the fmt library and 50265 is functionally > broken not just a performance issue. > > >
