Project

Profile

Help

Bug #3764

closed

Optimizing GeneralComparison to ValueComparison

Added by Michael Kay almost 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Performance
Sprint/Milestone:
-
Start date:
2018-04-27
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.9
Fix Committed on Branch:
9.9
Fixed in Maintenance Release:
Platforms:

Description

Saxon attempts to rewrite a GeneralComparison (x = y) as a ValueComparison (x eq y) when it is safe to do so. The reason for this is that a ValueComparison is simpler (and therefore fractionally faster) but more particularly because a ValueComparison is more amenable to further optimizations. For example an xsl:choose of the form

<xsl:choose>
  <xsl:when test="x = 1">...</xsl:when>
  <xsl:when test="x = 2">...</xsl:when>
  <xsl:when test="x = 3">...</xsl:when>
  <xsl:when test="x = 4">...</xsl:when>
</xsl:choose>

is optimized internally to a SwitchExpression provided that the conditions are all ValueComparisons.

This rewrite is not happening for the very common expression of the form (@x = 'value'). In fact, it is only done where both operands have static cardinality exactly one and in this case the LHS cardinality is zero-or-one. It's not clear why this is done, because the result of a ValueComparison when one operand is an empty sequence is effectively false, which works out fine.

Probably it's because (@x = 'value') returns false when @x doesn't exist, while (@x eq 'value') returns an empty sequence; so the rewrite is only safe in a context where we are only interested in the effective boolean value. But ValueComparison has a flag that can be set to force it to return false on empty, so we could set this flag.

Please register to edit this issue

Also available in: Atom PDF