Great..
I have seen expressions like :
translate($xxx, 'ABCDE','x');
which is to say, replace ABCDE with x .. this also works fine
is this not valid?
or should we do ..translate($xxx, 'ABCDE','xxxxx');
dak
On Mon, Sep 25, 2017 at 6:00 PM, Liam R. E. Quin liam(_at_)w3(_dot_)org
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
On Mon, 2017-09-25 at 17:42 +0000, Syd Bauman
s(_dot_)bauman(_at_)northeastern(_dot_)edu
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/
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--