Re: [xsl] Question on translate() function

Subject: Re: [xsl] Question on translate() function
From: "Liam R. E. Quin liam@xxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 25 Sep 2017 22:00:47 -0000
On Mon, 2017-09-25 at 17:42 +0000, Syd Bauman s.bauman@xxxxxxxxxxxxxxxx
> I have always presumed that translate() is faster than replace().[1]

I'd say, use whichever is clearer, braver, more noble. Take pity on
your future self trying to understand replace("[{]\\\$[()][}]", "#",

As for which is faster, it depends not only (as the inestimable Dr Kay
has expressed) upon the quality of the optimizer but for some
implementations the quality of the underlying code. Unfortunately there
are enough differences between XSLT and Perl regular expressions that
using libpcre has become difficult, as that library gets extensive
optimization outside of our universe and then returns through alternate
dimensions to dazzle us :)

> But I can't help it, sometimes -- I'd really like to know if
> translate() is significantly more efficient (computationally) than
> replace() or not.

There's no inherent reason why
  translate("abc", "ddd")
should be faster or slower than
  replace("[abc]", "d", "g")
once the parsing has been done; however, the work to recognize these
two cases may be easier for translate().

There are implementations that are faster than a freshly-oiled cow at
recognizing regular expression character classes, so if your input
string is, say, 100MBytes long, you might well be able to measure the
difference. In ASCII days there were implementations that used a bit
mask, and then you compare each input character (or four characters at
a time, say, using a wider mask) with the or'd mask and only do the
more expensive computation when needed. So an implementation using a
heavily optimized regular expression library might go faster with
replace() than translate(), because the XSLT/XPath/XQuery implementor
of translate() might not have done that sort of optimization.


Liam Quin, W3C,
Staff contact for Verifiable Claims WG, SVG WG, XQuery WG

Web slave for

Current Thread