jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter lin <peter....@labs.gte.com>
Subject JSTL <x:out > performance
Date Fri, 28 Jun 2002 17:41:26 GMT


I've been doing some benchmarks with JSTL's <x:> tags and I'm seeing
some performance quirks, which I do not completely understand. I'm
hoping someone here has more knowledge of jaxen, who can tell me if what
i am seeing is a limitation of jaxen. I don't see anything obvious in
JSTL's use of jaxen that would cause slowness, but comparing the
translation using <x:> tags vs XSLT w/Xalan &Xerces, I was expecting
better performance.

If I use "//" to get to the desired node, it can take twice as long to
select that node. For example:

a. <x:if select="count($dom//rsPages) > 1">

b. <x:if select="count($dom/results/listingPage/rsPages) > 1">

when I time each one, I get the following:

a. ~220ms
b. ~40ms

If half my xpath statements use "//", the performance is bad. To
translate 15 rows of data with the following structure using "//" takes
about ~320ms.

<listing id="00000001">
  <Name>
    <last>last</name>
    <first>first</name>
    <middle>middle</middle>
  </Name>
  <address>
    <streetno>00</streetno>
    <streetname>St</streetname>
    <city>city</city>
    <zip>00000</zip>
    <state>CA</state>
  </address>
  <ph desc="voice">
    <area>000</area>
    <exchange>000</exchange>
    <line>000</line>
  </ph>

  <url name="details">url</url>
  <url name="map_url">url</url>
  <url name="addrbk">url</url>
  <url name="directions">url</url>
</listing>

Whereas not using "//" results in the same process taking ~150ms. 
Another quirk I discovered is that using count() takes a performance
hit. Example below:

a. <x:if select="count($dom/results/listingPage/rsPages) > 1">
b. <x:if select="$dom/results/listingPage/pageInfo/totalpages[. > 1]">

In my tests, using count can add 5+ milliseconds depending on how many
<rsPages> nodes are in the document. My test pages show a difference of
~50ms. That doesn't sound bad at first, until you start throwing 16+
concurrent requests. Yet another example of a quirk:

a.
<x:if select="$dom/results/listingPage/pageInfo/totalpages[. > 1]">
<x:set var="listing_items" select="$dom/results/listingPage[.]"/>
<c:set var="next_prev"><x:out
select="$listing_items/rsPages[1]/pagename[.]"/></c:set>
<!-- use $next_prev for if & choose --->
<x:forEach var="number" select="$listing_items/rsPages">
</x:forEach>

b.
<x:forEach var="number" select="$dom/results/listingPage/rsPages">

Setting the node first and referncing off that results in performance
improvement. Using the second example can result in 2-3X increase.

I took a quick look a the ExprTag, ExprSupport and XPathUtil. It looks
it isn't doing any caching of nodes it's retrived. Is that true? If it
isn't, would the performance improve with caching?

peter lin

--
To unsubscribe, e-mail:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>


Mime
View raw message