问题
I have a function that uses a tree-like structure of dictionaries to match against incoming structures coming in at a rate of several 100k/sec.
It is already quite fast, but it needs to get even faster. In order to gauge how much faster it would get by compiling that piece of code in the most performant way, I hard-coded an optimized function for a particular tree of dictionaries, using nested switch statements (in this case, switching over bytes), and compared that to the dictionary-style version. As you would imagine, performance improvements were enormous: The hard-coded switch version needs only 20% of the CPU time of the dynamic Dictionary version.
As the tree is created dynamically at runtime and changes every now and then, I thought I could just dynamically CompileAssemblyFromSource the tree to a switch-statement version at runtime every time it changes, and I believe I would get the exact same performance that my hard-coded version gave me - except perhaps for the overhead of having to do a virtual method call instead of the static function call that I can do when calling a hard-coded function.
The problem is, the code thus generated cannot be unloaded from memory and will thus leak over time, unless I create the code in its own AppDomain, allowing me to unload it by unloading the whole AppDomain.
Here's the catch: Communication between AppDomains is more expensive than that inside a single AppDomain. And I assume the marshalling overhead will (more than?) destroy the gains of the switch-statements.
So is there any way to get native performance, for a dynamically changing problem like this, without leaking memory?
Or this there no way in .net to be both dynamically adaptive and statically fast? (Of course for this to make sense it is imperative that the number of calls vastly exceed the dynamism of the code in question.)
N.B. I am not concerned about time to compile the structure - it may take as long as it needs.
来源：https://stackoverflow.com/questions/31040998/possible-to-get-native-performance-for-dynamically-compiled-code-that-can-be-unl