Christian, I did some performance tuning a few weeks ago in DefaultNamStep.matches as far as I remember. The problem was mostly to do with resolving namespaces. Code was being called that wasn't needed when you had no namespace. When you have a namespace the resolving code is expensive (even though it looks harmless). I found this fact out using JProbe and after I tweaked it a bit I got ca. 10% gain. There are several other possible such candidates where tuning would help. Could you profile your old version v new version and see where the performance is being lost? Eddie ----- Original Message ----- From: Christian Nentwich <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 17, 2002 4:51 PM Subject: [Jaxen] performance trouble
> > All, > > something happened between when I last used jaxen (6 months ago?) and > the 1.0 release. Jaxen performs *worse* than Xalan now on my system, > perhaps excluding // expressions. > > That's a cause of concern... because I was going to allow Jaxen as a > plugin processor in my package because of its performance benefits. Any > ideas? > > Christian > > > > > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] > _______________________________________________ > Jaxen-interest mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jaxen-interest _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that’s a super model! Visit http://clustering.foundries.sf.net/ _______________________________________________ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
