Caching of reflection types - best practice?

[tg73]

Historically, in code that deals with reflection types, I've often stored the result of typeof in a readonly static field for performance reasons (at least where the type is used more than once). In the sample ML compile-time code that I've seen so far, this is not done. Is this just to keep the examples simple, or does ML magically remove the need for this manual optimization, and/or has modern .NET improved reflection performance so much that it's no longer needed?

Also should extra care be taken to avoid repeated identical calls to TypeFactory.GetType(...)? Are there any other Metalama.Framework.Code performance pitfalls to avoid?

I assume that objects from Metalama.Framework.Code must not be cached in aspect fields (static or instance) because those objects are dependent on the ambient compilation context, and compile-time aspect object lifetime may span multiple compilation contexts. Is that correct?

[gfraiteur]

You should never use compile-time static fields because, as you mentioned, their value depends on the compilation context, and static fields are shared across several compilations. Aspect classes are even serialized in cross-project scenarios (like cross-project inheritance) so you should design aspects as immutable classes.

You should not spend additional effort to cache calls to TypeFactory.GetType or similar methods because these are already cached. You should just pay attention to call these methods outside of loops.

Now if you are asking about caching System.Reflection objects in the run-time code generated by aspects, then yes, it's probably something you should take care of. Unlike PostSharp.IL, Metalama does not do that caching for you.