DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27717>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27717 ------- Additional Comments From [EMAIL PROTECTED] 2007-12-11 01:28 ------- Pushing this a bit - I don't think the problem is in x:foreach. I think it's in x:out. x:foreach executes relatively quickly, but then each execution of x:out is not cheap and it's adding up as the loop gets bigger. Presumably running the following is hurting: XPathUtil xu = new XPathUtil(pageContext); String result = xu.valueOf(XPathUtil.getContext(this), select); Digging into valueOf leads to agreement with David Winterbourne's comment in 40717 that the problem is in fillVarStack. It's in valueOf too and definitely looks like a culprit. So apologies for my last comment on 40717 being akin to CachedXPathAPI. That just caches the xpathSupport variable. Looking at the speed of things, I've not found where the slow down is yet. There are times when there are large chunks of slow down (100 milliseconds), which might be GC due to massive object creation. Also over time the general time taken on each eval call slowly rises, although still only to 10 milliseconds. Obviously I need to test in a profiler etc. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
