Talking about the caching of Expression trees (3): Using the prefix tree

In the previous article we managed to construct the prefix tree as a unique string and then cache the string as the key in the dictionary. The idea is straightforward, and it's not difficult to do so (the details are recorded over time). But in fact, when he was thinking about the caching of expression trees, the string concatenation was only in the mind, and the implementation was specially written for the integrity of this series of articles. This is because of its obvious drawbacks, as described above, string concatenation is a time-consuming and resource-intensive process, and it is easy to generate a large length string (not an optimization, but a complex implementation). So we now try to choose another solution to deal with this problem.

But now, let's consider another question: compare two strings for the same (for example, implement a String.Equals method). At this point, we tend to take a few steps:

Determines whether string lengths are equal and, if not unequal, two strings are definitely different.

Iterate two strings from scratch, and if you find a different one, two strings are the same.

If you complete the entire string, the two are the same.

The above algorithm is basically the most efficient comparison algorithm we can write. Why do you say that? The main reasons are as follows: two.

When we compare, we first use the most easily available information (length) to judge, and at the right time (find a different) timely return, save time.

There is no need to save complete information when comparing (when comparing the nth bits of the string, from 0 to n-1 characters are not retained), so it is also saved in space.

So let's think about why the string in the previous article is poor performance? In fact, he is precisely because of the violation of the above "characteristics":

The entire tree needs to be fully coded so that it is not possible to exclude all kinds of conditions through partial coding, and the time consuming is great.

The full path must be preserved, resulting in a long string, resulting in large space consumption.

Slightly different from string comparisons, since we are ultimately going to match exactly the same expression tree, a complete tree traversal is unavoidable, so the 1th may be difficult to change. What about the 2nd? Whether we can make a match without saving the previously traversed node, traversing to a "conflict" indicates that the match failed, and after a full traversal, the match was successful. To further see the need, let's say it clearly:

A complete traversal of an expression tree can be thought of as constructing a sequence of nodes (or "attributes" of nodes).

When traversing a sequence, you do not need to save the results of the traversal before. The end of the traversal indicates a successful match.

"Sequence", "Traversal", "match" ... Repeat in your mind several times, do you think of what? Yes, the above requirements seem to conform to our usual data structure: the prefix tree.