It’s common knowledge that reflection in .NET is slow, but why is that the case? This post aims to figure that out by looking at what reflection does under-the-hood.
This post is completely inspired by (or ‘copied from’ depending on your point of view) a recent post titled JAVA PAPERS (also see the HackerNews discussion). However, instead of looking at Java and the JVM, I’ll be looking at references to research papers in the .NET language, runtime and compiler source code.
A little over 2 years ago Microsoft announced that they were open sourcing large parts of the .NET framework and as Scott Hanselman said in his recent Connect keynote, the community has been contributing in a significant way:
Well it turns out that it’s a really nice example of collaboration between the main parts of the .NET runtime, here’s a list of all the components involved:
The dotnet
CLI tooling comes with several built-in cmds such as build
, run
and test
, but it turns out it’s possible to add your own verb to that list.
What’s the problem with LINQ? As outlined by Joe Duffy, LINQ introduces inefficiencies in the form of hidden allocations, from The ‘premature optimization is evil’ myth:
In the CLR strings are stored as a sequence of UTF-16 code units, i.e. an array of char
items. So if we have the string ‘testing’, in memory it looks like this:
In which we use System.Runtime.CompilerServices.Unsafe
a generic API (“type-safe” but still “unsafe”) and mess with the C# Type System!
If you’ve ever spent time debugging .NET memory dumps in WinDBG you will be familiar with the commands shown below, which aren’t always the most straight-forward to work with!