[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Question on translate() function

Subject: Re: Question on translate() function
From: "Liam R. E. Quin liam@xxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 25 Sep 2017 22:00:47 -0000
Re:  Question on translate() function
On Mon, 2017-09-25 at 17:42 +0000, Syd Bauman s.bauman@xxxxxxxxxxxxxxxx
wrote:
> 
> 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("[{]\\\$[()][}]", "#",
"g")...

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

-- 
Liam Quin, W3C, http://www.w3.org/People/Quin/
Staff contact for Verifiable Claims WG, SVG WG, XQuery WG

Web slave for http://www.fromoldbooks.org/

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.