There's certainly a cost associated with saxon:evaluate(), but the situation
you describe suggests that there are other factors at play here. If you're
getting dynamic errors then you need to work out why that is.
I suggest you start by measuring in a simpler single-process environment so
that you can get some predictable baseline measurements; only when these are
fully understood and replicable should you try to benchmark a
When doing any multi-user benchmark it's important to do a realistic
simulation of the expected workload. I'm no expert on modern Java
application servers - my experience in this area is all with mainframe-era
transaction processing monitors - but I'm sure the same factors apply,
namely that getting good response time depends critically on identifying the
resource bottlenecks and tuning the relevant system parameters. Once the
rate of arrival of work requests exceeds the throughput capability of the
server, response time will rise exponentially, and at that point the actual
response time tells you almost nothing: the only interesting figure is the
throughput level at which response time becomes unacceptable.
Performance in a multithreading environment is going to be less predictable
because of scheduling constraints and resource conflicts. It's possible that
the Saxon NamePool (which is updated under semaphore) is a bottleneck: this
would be something to investigate. If it is, you may be able to solve the
problem using multiple name pools.
If it turns out that saxon:evaluate is a significant contributor (and the
way to determine that is to do a control run that's identical except for the
use of saxon:evaluate), then the obvious way to improve things is by
caching. You can split saxon:evaluate into two phases, saxon:expression
which parses the expression and saxon:eval which evaluates it. The expensive
phase is the first one, and you need to organize your application so each
expression is only compiled once, and then cached.
> -----Original Message-----
> From: saxon-help-admin@...
> [mailto:saxon-help-admin@...] On Behalf Of
> Merico Raffaele
> Sent: 23 December 2004 07:47
> To: saxon-help@...
> Subject: [saxon] Performance saxon:evaluate()
> Dear Michael Kay, dear list
> I'm sure that you remember my enthusiastic words on saxon:evaluate().
> Based on saxon:evaluate() I have developed a XML-Template-Trax that
> processes XML templates (i.e. XHTML) containing any XPATH
> expressions. I
> think that this approach is good because it separates nearly
> all of the XSL
> logic from the templates and it allows web designer to work
> with well known
> (X)HTML templates.
> Using this solution with cocoon I noted that the execution
> time for exactly
> the same test-transformation with only one user varied from
> 13 ms to 700 ms.
> Additionally form time to time I got the
> Yesterday than I did a benchmark test (5 parallel users, totally 100
> requests). I was nearly destroyed when I saw an execution
> time in the range
> between 3 to 11 seconds.
> Now, before I stop to dream and I but away this approach I
> would like to
> know if this situation/result is obvious to you. Are dynamic
> evaluated XPATH
> expressions always so inefficient? Do you see any alternative?
> For your support many thanks in advance, kind regards
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from
> real users.
> Discover which products truly live up to the hype. Start reading now.
> saxon-help mailing list