On the caching of Expression trees (4): Using a two-fork search tree (AVL tree)

In the previous article, we talked about the prefix tree implementation, the time complexity in theory has reached the optimal, and the space complexity can theoretically be better. But there is a difference between theory and practice, and for the implementation of the prefix tree above, these two aspects are not ideal:

Time: The prefix tree time complexity O (m) is the premise of each hash table lookup operation time Complexity of O (1), but this O (1) compared with a numerical comparison, there is still a significant difference in performance.

Space: The prefix tree space complexity is better than the premise is "fine" to achieve the data structure, if the same as the above carelessness, then a large number of sparse hash table, but caused space waste.

Therefore, although the prefix tree is actually the first real implementation of the caching method, but not satisfied with this, but also think of what methods can be optimized.

As mentioned earlier, the low performance of using strings for full encoding is one reason for the fact that only a full code can obtain the final result and then compare it with other elements in the dictionary. The obvious fact is that comparing the two expression trees to the same does not require them to be fully coded, if we "manually" compared, often as long as a node to compare the nodes, as long as a node to find a different, you can get the conclusion. But just comparing the two expressions is the same and cannot be queried and sorted, we have at least a size relationship between the two expression trees so that we can sort them before we can find them, for example, we can put them in a linear table and keep the sort state at all times, so we're ready for a binary lookup.

To get the size relationship between the two expression trees is exactly the same as the time complexity of getting them equal, in fact they are implemented almost exactly the same way, simply by returning 1, 0 or-1 when the result is obtained, rather than a simple Boolean value. Do one such comparison time complexity is O (m), m for the traversal sequence shorter expression tree length. However, as you can see from previous analysis, the performance of comparing two "random" expression trees is quite high, because we can return the result immediately if we find that there are some differences.

Unfortunately, it's not easy to implement one of these comparisons because ExpressionVisitor can only be used to traverse a single expression tree and not operate two at a time. However, as long as we imitate the expressionvisitor traversal, "at the same time" traversing the two expression tree can be. So we're now going to implement the core function of the algorithm: Expressioncomparer. As follows:

public class Expressioncomparer:icomparer<expression>
{
public virtual int Compare (Expression x, Expression y)
{
int result;
if (This.comparenull (x, y, out result) return result;

result = This.comparetype (X.gettype (), Y.gettype ());
If (Result!= 0) return result;

result = X.nodetype-y.nodetype;
If (Result!= 0) return result;

result = This.comparetype (X.type, Y.type);
If (Result!= 0) return result;

Switch (x.nodetype)
{
Case Expressiontype.negate:
Case expressiontype.negatechecked:
...
Return This.compareunary ((unaryexpression) x, (unaryexpression) y);
Case Expressiontype.add:
Case expressiontype.addchecked:
...
Return This.comparebinary ((binaryexpression) x, (binaryexpression) y);
Case Expressiontype.typeis:
Return This.comparetypeis ((typebinaryexpression) x, (typebinaryexpression) y);
Case Expressiontype.conditional:
Return This.compareconditional ((conditionalexpression) x, (conditionalexpression) y);
Case Expressiontype.constant:
Return This.compareconstant ((constantexpression) x, (constantexpression) y);
...
Default
throw new Exception (string. Format ("Unhandled expression type: ' {0} '", X.nodetype));
}
}

...
}