Fasterflect vs. C# 4.0 Dynamic
As .NET 4.0 final release will hit the market pretty soon, it’s worth discussing the value of Fasterflect in the face of C# 4.0’s dynamic keyword. (If you aren’t familiar with C# 4.0 dynamic, you should read my article on C# 4.0 before continuing.)
To recall, Fasterflect was designed to address 2 key disadvantages of .NET Reflection: ease of use and performance. As seen in my article about C# 4.0, the dynamic keyword nicely addresses the easy of use with a resulting syntax looking even nicer than Fasterflect. How about performance?
I improved the benchmark application of Fasterflect to add some benchmark code comparing between the performance of C# 4.0 dynamic and Fasterflect. Here is result of method invocation benchmark.
While performing slower than Fasterflect’s cached API, C# dynamic performs much better than Fasterflect’s standard API. (Not surprisingly, the C# dynamic binding doesn’t resort to the slow reflection mechanism internally.)
With this awareness in mind, together with the understanding about the features of C# dynamic and Fasterflect, let’s discuss about areas where Fasterflect shines even in the face of C# 4.0 dynamic:
- C# dynamic doesn’t handle invocations performed based on dynamic information (i.e. field name read from XML file).
- C# dynamic does handle certain types of dynamic invocations, including static method invocation, static property invocation and constructor invocation.
- C# dynamic doesn’t handle non-public members. So you’ll receive exception if trying to, say, invoke a private method.
- When performance is more critical than readability then the Fasterflect’s cached API might be favored over C# dynamic.
Granted, there should be workarounds for the first 3 items. For example, if you want to invoke static method dynamically with C# dynamic, you would have to workaround like the approach described in this article. However, the approach uses reflection behind the scene so you would have the same performance issue to start with.
This doesn’t say that Fasterflect is better than C# dynamic though. While both share a couple of features and maybe used interchangeably in some scenarios, they also have different problems of their own to address. There are many things that you can do with C# dynamic that you couldn’t do with Fasterflect, e.g. implementing an interceptor to dynamically handle all method invocations (or missing methods) etc. So, pick the right tool for your problem at hand.
Could you please suggest a scenario where developer may need to use Fasterflect? You made it for your project, didn’t you?
@Thoai: very simple: whenever you need to use .NET Reflection to perform dynamic invocation (e.g. construct type whose name is read from XML), you can use Fasterflect with the latter being more intuitive and faster. Specific scenarios include: implement the mapping layer of an ORM framework, factory pattern, or plugin support etc.
Hi Mr. Buu,
It is an interesting library. But when compare to C# 4.0 Dynamic, I think you have to make clear some problems:
_ I think it uses Emit to build a dynamic codes, is it? As I remember, Emit cause some security problem when deploy in strict environment( such as ASP.NET for shared host)?
_ C# 4.0 Dynamic is for wider uses. Your comparison should define the area that two compared to.
_ Do you solve problem for overloading methods when invoke? Example:
class A
{
public void MethodA(object obj){}
public void MethodA(object obj, ref int i){}
public void MethodA(Customer cus){}
}
Are there any problem when I call MethodA with parameter is a Customer? a Object? and how to get return integer from calling second method?
_ I know a way to construct an object that you can compete with. You can reflector the way BinarySerializer construct an object. (It do not call the constructor of object. So you can construct a object that DO NOT have any parameterless constructor).
Above questions are problems of my library
. I have my own solution, but C# 4.0 Dynamic do better than mine.
Besides, this library is a good one. What is roadmap for this library? Do you continue to build it to an IoC container ( setter injection or construct injection …)?
Thanks
HuyHM
@HuyHM:
.NET Reflection alone would not be allowed in Medium-trust environment, so my library doesn’t make anything worse on that respect, but it also doesn’t improve anything either (because as you correctly spotted out, it uses Reflection Emit).
Methods with multiple overloads can be invoked without any problem: just specify the parameters’ types properly and Fasterflect will resolve to the correct overload. You can also retrieve the out/ref parameter with Fasterflect. (See the test method named Test_invoke_method_with_ref_params_without_returning() in MethodTest.cs of the unit test project.)
No, I don’t plan to make Fasterflect become an IoC container. But I can see how people can use it as the basis to build ORM, IoC container and other kinds of frameworks which need to perform many invocations.
I have a couple of ideas to improve Fasterflect, you can see them here: http://fasterflect.codeplex.com/WorkItem/List.aspx. Feel free to suggest others
.