This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: grouping headers


Hi Jeni,

tnx again for catching my error. I have been wondering about what makes
an XSLT program go faster and have not yet been able to guess correctly
in advance which way of doing things is faster :(.

I tried your suggestion of using xsl:key instead of my (fixed up) rather
plodding solution. I found no significant difference in the performance
of the two.

Of course this was an off the cuff test, wall clock by eye measurment,
and who knows what artifacts I introducted in doing it, but here is what
I found using MSXML3 and Saxon 6.2.2.

I made two test files, one with 2000 people in it and the other with
5000 people in it. The city and name contents were pretty much random
text. The people were randomly distributed over 10 cites. I did my best
to make sure all of the of elements were in random order too. Times in
min:sec

people    2000   5000

Saxon      
plodding  0:25   2:17
key       0:23   2:08

MSXML
plodding  0:13   1:12
key       0:12   1:08

So the key is faster, but by less than 10% on the small file and less
than 5% on the large one. 

Dan


-----Original Message-----
From: Jeni Tennison [mailto:mail@jenitennison.com]
Sent: Friday, August 24, 2001 9:25 AM
To: Sullivan, Dan
Cc: XSL-List@lists.mulberrytech.com
Subject: Re: [xsl] grouping headers


Hi Dan,

>         <xsl:apply-templates
> select="person[preceding-sibling::person[city]!=city]">

I think you meant:

  person[preceding-sibling::person/city != city]

but you have to be a bit careful when you use != with node sets. The
above predicate will test whether there are *any* preceding person
elements whose city is not equal to the context person's city. So if
you have:

  <person><city>Amsterdam</city></person>
  <person><city>Madrid</city></person>
  <person><city>Amsterdam</city></person>
  <person><city>Madrid</city></person>

then it will actually be false for the first person (because it there
are no person elements before it), and true for the rest of the person
elements (because they each have at least one preceding person with a
different city).

What you want is:

  person[not(preceding-sibling::person/city = city)]

in which the predicate tests whether it's not the case that there is a
preceding person's city equal to the context person's city, i.e. those
that are first with a particular city. This is true for the first and
second person in the above XML, and false for the other two.

(It's usually better still to use keys because they're more efficient,
but that's a different issue.)

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]