Saxon

Legacy ID: #5162350 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

A correction, <xsl:analyze-string regex="\p{{L}}" flags="imx" select="$expression">

Legacy ID: #5163906 Legacy Poster: Michael Kay (mhkay)

Could you please illustrate a complete stylesheet with -explain output? Don't be misled by the fact that the initial code generated contains things like concat() and string-join(). These should be optimized in subsequent phases by the compiler. Michael Kay Saxonica

Legacy ID: #5164775 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

This is probably too large for an example, but it illustrates what's happening. Please see: http://www.nesterovsky-bros.com/download/xslt/expression-parser.xslt in particular p:tokenize-expression() function. Thanks.

Legacy ID: #5164862 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

I've rechecked the code. concat() is indeed optimized into literal string, however the decision is already made: AnalyzeString is constructed without precompiled pattern. Thus in the following code Saxon repeatedly recompiles regex: private RegexIterator getRegexIterator(XPathContext context) throws XPathException { CharSequence input = select.evaluateAsString(context); RegularExpression re = pattern; if (re == null) { CharSequence flagstr = flags.evaluateAsString(context); final Platform platform = Configuration.getPlatform(); final int xmlVersion = context.getConfiguration().getXMLVersion(); re = platform.compileRegularExpression( regex.evaluateAsString(context), xmlVersion, RegularExpression.XPATH_SYNTAX, flagstr); if (re.matches("")) { dynamicError("The regular expression must not be one that matches a zero-length string", "XTDE1150", context); } } return re.analyze(input); }

Legacy ID: #5166699 Legacy Poster: Michael Kay (mhkay)

Thanks, I will look at this on my return from vacation. Michael Kay http://www.saxonica.com/

Legacy ID: #5201172 Legacy Poster: Michael Kay (mhkay)

Thanks, you are quite right. I don't normally issue patches for performance improvements but I decided to make an exception in this case. See https://sourceforge.net/tracker/index.php?func=detail&amp;aid=2079053&amp;group_id=29872&amp;atid=397617. The patch affects module AnalyzeString.java - as well as handling the case that you identified where the regex contains doubled curly braces, it handles any other case where the AVT has been reduced to a constant string by the end of the optimization phase. I'm a bit puzzled by this one because I distinctly remember looking at the case where the user writes <xsl:variable name="regex">xxxxxx</xsl:variable> <xsl:analyze-string regex="{$regex}"> and ensuring that this was optimized correctly. But I can't find any trace of the code to do that. I've checked however that with the patch this case is now handled.