Re: [xsl] How to use xsl:key to make my XSLT program super-efficient?

Subject: Re: [xsl] How to use xsl:key to make my XSLT program super-efficient?
From: "Graydon graydon@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 12 Mar 2025 12:46:40 -0000
On Wed, Mar 12, 2025 at 11:50:52AM -0000, Roger L Costello
costello@xxxxxxxxx scripsit:
> I have a huge (1.2GB) XML document containing air navigation data. I
> need to convert the XML document to another XML format, i.e., it is an
> XML-to-XML translation task.
...
> My XSLT needs to be super-efficient because the XML document is huge,
> and I need to perform a lot of processing. 

You can't know by inspection how efficient your XSLT is, and it's
generally pretty futile to try to make it efficient before you write it
beyond basic things like avoiding polynomial algorithms. 

Nigh-any declarative language is a dialog with the optimizer and it's
generally beneficial to approach it that way; write something that
works, meaning "I am confident by testing the output that this is doing
the right thing", and then use `-T` or similar to find out exactly where
it isn't efficient and then address that specific part.

> When I think of "efficiency" what comes to mind is the xsl:key/key() pair.

Keys are the grandparent of maps, and you've got (or at least I
sincerely hope you're using 3, and have got) maps. A map of some atomic
type identifier to ARPT element works as a reference to the existing
ARPT element, rather than a copy, so you aren't looking at a lot of
overhead to map the ARPT elements.

> I need to iterate over each airport record, i.e., iterate over each <row> element within the <ARPT> element. I figured that the following xsl:key/key() pair will enable me to iterate efficiently:

If it's really iterate, use xsl:iterate.

I think you may mean process, and for that template matching should be
fine. In general, template matching is pretty fast; you can make it
not-fine by sticking something expensive in the predicate (at least at
one time, preceding-sibling or following-sibling could get very
expensive) but the fix for that is multiple passes, each of which does
something simple.

Is this a change-the-element-names process or a rearrange-the-data
process?

-- Graydon

--  
Graydon Saunders  | graydonish@xxxxxxxxxxxx
\xDE\xE6s ofer\xE9ode, \xF0isses sw\xE1 m\xE6g.
-- Deor  ("That passed, so may this.")

Current Thread