On the caching of Expression trees (7): Total analysis of five kinds of caching methods and the improvement scheme

Finally to the last article in this series, this series of articles this is the basis of many topics, but dragged so long has not been completed. This article focuses on the pros and cons of the five caching methods, and where their performance keys are, and what options are available if they are to be improved. On this issue, Lao Zhao's thinking may be omitted, if you have any additional, please do not hesitate to point out.

Simplekeycache

Simplekeycache is the most direct caching scheme: the expression tree is fully encoded, transformed into a unique string, and then stored as a key in the dictionary.

From the experiment in the previous article, Simplekeycache is the worst of the five caching schemes, both in terms of time consuming and the pressure on the GC. This is easy to understand. Because in the. NET concatenation of strings is a relatively large consumption of operations. The entire encoding of an expression tree is bound to store all of its information in a string. You will find, for example, that the type or memberinfo information in each node of the expression tree takes up more space, while the number of nodes within an expression tree can be considerable. The two complement each other, making the cost of constructing a string very significant.

But what are the advantages of Simplekeycache? The advantage of this is that it is the only scenario in the five caching scenarios that can be reproduced arbitrarily. That is, no matter what machine it is, the encoding result of the same expression tree is unchanged, regardless of which time it was started. This is also necessary to implement "distributed storage". The various caching schemes mentioned in the previous article are implemented within a single process, so as long as some of the necessary information does not change after the program is started (for example, an object's GetHashCode call result). However, when the distribution is stored, multiple processes will appear, and if the "keys" they produce cannot be kept unchanged, the same expression tree cannot be used for sustainable communication.

If you really use an expression tree as an identifier in a "distributed storage" environment, or in other scenarios that require a "stable" feature (such as storing an expression tree in a database), then your choice might be to optimize the coding scheme. For example, you can fragment the final string, write information about the type object in the header, and specify a short identifier for it so that you can omit duplication of data in the body of the string.

However, complex coding can also result in additional operational overhead, which is not necessarily beneficial for performance. Therefore, before reaching a definite conclusion, it is necessary to evaluate the implementation performance, do not feel, but use the data to speak.