When porting from the .Net Framework 4.5 to a Portable Class Library profile or Windows Store apps, a big change for Reflection-heavy libraries and applications is transitioning over to the Evolved Type System, i.e. moving from Type
to TypeInfo
.
It might be tempting to do it the easy way and transform a lot of code from this:
someType.AccessReflectionAPI();
...to something like this:
someType.GetTypeInfo().AccessReflectionAPI();
This makes a lot of GetTypeInfo
calls, which leaves me worrying. Since in the .Net Framework 4.5 TypeInfo
derives from Type
, the GetTypeInfo
implementation is trivial (and might even be JIT-inlined?), but what about the implementation for Windows Store Apps and .Net Core?
How big of an impact is calling GetTypeInfo on those platforms? Will each call create a new object? Will each call mean a dictionary lookup? What's the overhead here?
GetTypeInfo being a static reflection method will not create new objects, so the only overhead is speed. You're correct in that most of reflections guts are JIT inlined, and C++/CLI based code - performance really isn't a problem from my experience.
If you're interested the reflection api's internals are pretty simple to reason about if you look through mscorlib in reflector or another assembly inspector.