问题
I am investigating an issue latency issues that happens soon after a server (having multiple services) starts.
I've added a simple method that loads of referenced DLLs and performs RuntimeHelpers.PrepareMethod on every method in every type in every assembly in those DLLs, effectively JIT-ing the entire codebase (of one specific service). This is performed using Parallel.ForEach and takes just a couple of seconds (with 100% on a quad-core processor). This reduces the latency issues on the first calls to almost nothing (because I am not JIT-ing generic methods). It also comes with a very low price, just a couple of seconds in the initialization of the service.
However my team leader claims that this type of modification to the server will not go in production because it's "not safe" and might bring unexpected results, and he mentioned dynamically loading (and unloading?) DLLs.
Is it true that what I have described might bring unexpected results, exceptions, etc?
Is the way Windows manages services affects RuntimeHelpers.PrepareMethod (or vice-versa) ?
Is it different then doing the same (pre JIT-ing all methods) in a regular Windows Application?
Does it conflict with a DI (we are using IOC) ?
If we are dynamically loading DLLs, can it interfere in any way?
And generally, what harm can it give?
回答1:
He is almost definitely wrong.
Calling this function will not "break" the CLR.
However, it can cause the JITter to load assemblies earlier than it otherwise would have.
If you add AssemblyResolve handlers later, they will no longer help, since the CLR will have already tried to load the relevant assemblies.
来源：https://stackoverflow.com/questions/26590809/disadvantages-of-runtimehelpers-preparemethod-in-a-windows-service