I'm writing a library in C# that I will later use for an application, and I want the library to be as efficient as sanely possible (ie. don't over-complicate things too much to make it more efficient). However, I have this question about how to most efficiently use reflection on a class/methods and to illustrate the question I've simplified my class a lot down to this:
class MyClass
{
private static Dictionary<string, object> methods;
public void Method1()
{
// Do something.
}
public void Method2()
{
// Do something else.
}
}
Now, what I want is from within the class (a private method yet to be created), take a string containing the method-name, then fire the method, simple as that. The easiest way of doing this would be to just look at the name, get a method with that name, and execute it, but that forces me to use reflection a lot of times. This private method can potentially be called thousands or tens of thousands of times, and it need to be quick. So I came up with two possible solutions. As you can probably see I've added a static dictionary containing string->object (replacing object with actual type, just wrote object cause that works with both my examples). Then I'd add a static constructor that goes trough the class and adds all the methodinfos to the methods-dictionary. And then comes the question, on creation of a new instance of the class, should I create bound delegates to the methods and put those in a non-static private dict, or should I simply fire the methods using the MethodInfo in the methods-dictionary?
The average use-case will create 10 instances of this class, and have 1000+ calls to the method that should fire either Method1 or Method2 depending on it's string-argument (and no, switch-case is not an option because of the extensibility of the class, as said, this was a simplified version). What would be the most efficient way of achieving this?
Obviously no one can answer the question without actually trying it and doing performance tests to see if your goal is met or not.
Reflection is a lot faster in modern versions of the framework than it used to be, but it still is not as fast as simply invoking a delegate.
My suggestion would be to start with your proposed solution: build the cache of method infos once:
class MyClass
{
static Dictionary<string, MethodInfo> cache = new ...
public void InvokeByName(string name)
{
MethodInfo methodInfo = GetMethodInfoFromCache(name);
methodInfo.Invoke(this, new object[] {});
}
When asked to invoke a method identified by a string on a particular instance as the receiver, look up the method info by name and then invoke it with the given receiver. Measure the performance of that and see if it meets your goal. If it does, great; don't waste any more of your valuable time trying to make something faster that is already fast enough.
If that is not fast enough then here's what I'd do:
class MyClass
{
static Dictionary<string, Action<MyClass>> cache = new ...
public void InvokeByName(string name)
{
GetActionFromCache(name).Invoke(this);
}
So what does GetActionFromCache do? If there is already an action in the cache, we're done. If there is not, then obtain the MethodInfo via Reflection. Then use the Expression Tree library to build up a Lambda:
var methodInfo = SomehowGetTheMethodInfo(name);
// We're going to build the lambda (MyType p)=>p.<named method here>()
var p = Expression.Parameter(typeof(MyType), "p"));
var call = Expression.Call(p, methodInfo);
var lambda = Expression.Lambda<Action<MyType>>(call, p);
var action = lambda.Compile();
And now you have an action in hand that you can invoke with the instance. Stick that thing in the cache.
This is, incidentally, at an incredibly simplified level, how "dynamic" works in C# 4. Our problem is enormously complicated by the fact that we have to deal with the receiver and arguments being of any type. You have it very easy comparatively.
Since you will obtain all of the MethodInfo instances and the name to map them to (presumably through the MethodInfo.Name property, you can go one step further and create a compiled lambda expression in the form of a delegate which you can execute.
First, it's assumed that all of your methods will have the same signature. In this case, it's an Action<T> delegate. With that, your dictionary will look like this:
// No need to have the dictionary **not** readonly
private static readonly IDictionary<string, Action<MyClass>> methods =
new Dictionary<string, Action<MyClass>>;
Then, in your static constructor, you would use reflection to get all of the MethodInfo instances:
static MyClass()
{
// Cycle through all the public instance methods.
// Should filter down to make sure signatures match.
foreach (MethodInfo methodInfo in typeof(MyClass).
GetMethods(BindingFlags.Public | BindingFlags.Instance))
{
// Create the parameter expression.
ParameterExpression parameter = Expression.
Parameter(typeof(MyClass), "mc");
// Call the method.
MethodCallExpression body = Expression.Call(pe, methodInfo);
// Compile into a lambda.
Action<MyClass> action = Expression.Lambda<Action<MyClass>>(
body, parameter).Compile();
// Add to the dictionary.
methods.Add(methodInfo.Name, action);
}
}
Then, your private method would look like this:
private void ExecuteMethod(string method)
{
// Add error handling.
methods[method]();
}
The benefit here is that you get the performance of compiled code, while paying a very small price (IMO) in code complexity (in creating the delegate). Granted, there is a slight overhead in calling the code through a delegate, but that's been vastly improved (it had to be with the introduction of LINQ, since they would be executed many, many times).
If I had the choice here, I would probably go with Henk's suggestion and use dynamic. Method invocations are blazingly fast (much faster than ordinary reflection and almost like normal method calls).
You may also find inspiration by looking at this class, which extends DynamicObject and illustrates how you could do the dynamic invocation of methods.
However, if you wish to support 3.5 or keep your options open and you have no objections to using a 3rd party library, then this can still be fairly easily accomplished:
void Invoke( string methodName )
{
this.CallMethod( methodName );
}
CallMethod creates a DynamicMethod delegate for invoking that particular method and caches it in case you call the same method again. There are also extensions for invoking methods with parameters and a ton of other useful reflection helpers.
If you prefer to cache the delegate yourself (we use a ConcurrentDictionary and WeakReferences to do this, which means it might get garbage collected), just call DelegateForCallMethod instead.
The library supports both 3.5 and 4.0. WP7 does not support Reflection.Emit and therefore cannot use IL generation and DynamicMethod. However, WP 7.5 does support this (but Fasterflect, as the library is called, does not yet support it).
From your comment:
Well, simply put it's connected to a server, the server sends commands in the form of <name> <param1> <param2> ... <paramN>, and the name determines what functionality should be performed. I want to be able to just add functions with matching names (or rather, I've created an attribute that lets me name methods other than their method-name cause command-names might be numeric), cause the list of names is looooong, and I don't want to do a switch-case.
You can solve this problem with a simple command interface and a table-driven factory for a matching instance (or a type, if the command instances are not reusable).
public interface ICommand {
void Execute();
}
public class Processor {
private static Dictionary<string, ICommand> commands;
static Processor() {
// create and populate the table
}
public void ExecuteCommand(string name) {
// some validation...
commands[name].Execute();
}
}
No reflection involved.
To create a new command, just create a new class that implements ICommand and add the corresponding line to the commands table inside the Processor static constructor.
public class FooCommand : ICommand {
public void Execute() {
// foo away!
}
}
...
public class Processor {
static Processor() {
...
commands["foo"] = new FooCommand();
...
}
}
There are many advantages to this design, aside from performace. Your commands are isolated from each other, changes to one command or the creation of new commands won't impact other commands. They're better testable and easier to maintain. Even the processor can be closed (in an OCP way) if you can maintain your table in a config file or a database, for example.
You can certainly find alternative designs and ways to pass parameters to the commands, but I hope this gives you the basic idea.
In this particular case you can declare your dictionary slightly differently and get the result you are after::
class MyClass
{
private static Dictionary<string, Action<MyClass>> methods;
public void Method1()
{
// Do something.
}
public void Method2()
{
// Do something else.
}
static MyClass(){
methods = new Dictionary<string, Action<MyClass>>();
foreach(var method in typeof(MyClass).GetMethods(
BindingFlags.Public | BindingFlags.Instance)
)
{
methods.Add(
method.Name,
Delegate.CreateDelegate(typeof(Action<MyClass>),method)
as Action<MyClass>);
}
}
}
This code has the advantage of not using code generation. However if you have methods of different signatures then a different approach will be needed. Here we are creating open instance delegates. (Note this doesn't always work correctly if MyClass is a struct or if any of these methods are generic virtual methods).
The fastest way of doing something is not to do it at all. Have you considerer just making interface like:
interface ICallMe
{
void CallByName(string name, object args);
}
This way if some of the implemetations wants to be insanely smart it can do reflection+caching+IL generation, the others can simply use if/switch.
Downside - significantly less fun to implement and debug.
Invoking a MethodInfo is slow. So I think creating a new dictionary for each instance should be good enough. Another option is to create a delegate that accepts the instance (Action<MyClass>) using Expressions (and then store them in the static dictionary):
MethodInfo method = typeof(MyClass).GetMethod("Method1");
var parameter = Expression.Parameter(typeof(MyClass));
var call = Expression.Call(parameter, method);
var lambda = Expression.Lambda<Action<MyClass>>(call, parameter);
Action<MyClass> del = lambda.Compile();
Have you considered using Code Generation and T4 Text Templates?
http://msdn.microsoft.com/en-us/library/bb126445.aspx
http://msdn.microsoft.com/en-us/library/bb126478.aspx
Then you could use a case statement.
Something like
partial Class MyClass
{
public void Exec(string funcToExec)
{
swtich(funcToExec)
{
<#
foreach(MethodInfo mi in
typeof(MyClass).GetMethods(BindingFlags.Public | BindingFlags.Static)
{
if(mi.Name != "Exec"){
#>
case : "<#= mi.Name #>"
<#= mi.Name #>();
<#
}}
#>
}
}
}
Related
I have a generic method that takes a request and provides a response.
public Tres DoSomething<Tres, Treq>(Tres response, Treq request)
{/*stuff*/}
But I don't always want a response for my request, and I don't always want to feed request data to get a response. I also don't want to have to copy and paste methods in their entirety to make minor changes. What I want, is to be able to do this:
public Tre DoSomething<Tres>(Tres response)
{
return DoSomething<Tres, void>(response, null);
}
Is this feasible in some manner? It seems that specifically using void doesn't work, but I'm hoping to find something analogous.
You cannot use void, but you can use object: it is a little inconvenience because your would-be-void functions need to return null, but if it unifies your code, it should be a small price to pay.
This inability to use void as a return type is at least partially responsible for a split between the Func<...> and Action<...> families of generic delegates: had it been possible to return void, all Action<X,Y,Z> would become simply Func<X,Y,Z,void>. Unfortunately, this is not possible.
No, unfortunately not. If void were a "real" type (like unit in F#, for example) life would be a lot simpler in many ways. In particular, we wouldn't need both the Func<T> and Action<T> families - there'd just be Func<void> instead of Action, Func<T, void> instead of Action<T> etc.
It would also make async simpler - there'd be no need for the non-generic Task type at all - we'd just have Task<void>.
Unfortunately, that's not the way the C# or .NET type systems work...
Here is what you can do. As #JohnSkeet said there is no unit type in C#, so make it yourself!
public sealed class ThankYou {
private ThankYou() { }
private readonly static ThankYou bye = new ThankYou();
public static ThankYou Bye { get { return bye; } }
}
Now you can always use Func<..., ThankYou> instead of Action<...>
public ThankYou MethodWithNoResult() {
/* do things */
return ThankYou.Bye;
}
Or use something already made by the Rx team: http://msdn.microsoft.com/en-us/library/system.reactive.unit%28v=VS.103%29.aspx
You could simply use Object as others have suggested. Or Int32 which I have seen some use. Using Int32 introduces a "dummy" number (use 0), but at least you can't put any big and exotic object into an Int32 reference (structs are sealed).
You could also write you own "void" type:
public sealed class MyVoid
{
MyVoid()
{
throw new InvalidOperationException("Don't instantiate MyVoid.");
}
}
MyVoid references are allowed (it's not a static class) but can only be null. The instance constructor is private (and if someone tries to call this private constructor through reflection, an exception will be thrown at them).
Since value tuples were introduced (2017, .NET 4.7), it is maybe natural to use the struct ValueTuple (the 0-tuple, the non-generic variant) instead of such a MyVoid. Its instance has a ToString() that returns "()", so it looks like a zero-tuple. As of the current version of C#, you cannot use the tokens () in code to get an instance. You can use default(ValueTuple) or just default (when the type can be inferred from the context) instead.
I like the idea by Aleksey Bykov above, but it could be simplified a bit
public sealed class Nothing {
public static Nothing AtAll { get { return null; } }
}
As I see no apparent reason why Nothing.AtAll could not just give null
The same idea (or the one by Jeppe Stig Nielsen) is also great for usage with typed classes.
E.g. if the type is only used to describe the arguments to a procedure/function passed as an argument to some method, and it itself does not take any arguments.
(You will still need to either make a dummy wrapper or to allow an optional "Nothing". But IMHO the class usage looks nice with myClass<Nothing> )
void myProcWithNoArguments(Nothing Dummy){
myProcWithNoArguments(){
}
or
void myProcWithNoArguments(Nothing Dummy=null){
...
}
void, though a type, is only valid as a return type of a method.
There is no way around this limitation of void.
What I currently do is create custom sealed types with private constructor. This is better than throwing exceptions in the c-tor because you don't have to get until runtime to figure out the situation is incorrect. It is subtly better than returning a static instance because you don't have to allocate even once. It is subtly better than returning static null because it is less verbose on the call side. The only thing the caller can do is give null.
public sealed class Void {
private Void() { }
}
public sealed class None {
private None() { }
}
I'm curious to understand what's happening behind the scenes in a situation like this:
public static void OuterMethod() {
// some random code
var a = 42;
var b = "meaning of life";
Func<string, object> factory = (aString) {
// do something with a and b
return "Hello World";
};
// some more random code
factory("My string");
}
I'm particularly interested in cases where OuterMethod is called very often. In my case it's the MVC request pipeline where OuterMethod is called once for each request.
Am I incurring a lot overhead by having to build factory each time the method is called? I could easily move the Func outside of OuterMethod into its own static method however in my actual scenario because it is defined inside I have access to a lot of variables I need to do my calculation that I would otherwise need to include in the signature of a method defined outside. Maybe this is just a micro optimization but I would like to better understand how the compiler treats these kinds of statements.
The actual lambda is going to result in a new named method (you just don't know what that name is) being created at compile time (the exact semantics will vary based on some of the specifics).
The only work being done on each invocation of the method is the creation of a new delegate object that has its own pointer to the same named method. If constructing that one object instance is really too much for you (hint: its not) then you could save that work by extracting the delegate out of the method.
I'm trying to write a class which can handle many different types of inputs, all of which implement the same interface.
I have the following code:
private IEnumerable<IPlan> DevisePlans(ITile tile, IEnumerable<ISpace> spaces)
{
MethodInfo method = GetType().GetMethod("DevisePlans",
BindingFlags.NonPublic | BindingFlags.Instance,
null,
new[] {tile.GetType(), typeof(ISpace)},
null);
var type = typeof(Func<,,>).MakeGenericType(tile.GetType(), typeof(ISpace), typeof(IEnumerable<IPlan>));
var planner = Delegate.CreateDelegate(type, this, method);
return spaces.SelectMany(s => (IEnumerable<IPlan>)planner.DynamicInvoke(tile, s));
}
There are lots of various implementations of DevisePlans within the class, each with a first parameter type that implements ITile.
private IEnumerable<IPlan> DevisePlans(Foo tile, ISpace space) { /* ... */ }
private IEnumerable<IPlan> DevisePlans(Bar tile, ISpace space) { /* ... */ }
This works, but I'm calling DynamicInvoke for every single iteration of my enumerable. Even if I can't completely avoid the dynamic call, is there any way to optimize this method so that the dynamic invocation no longer resides within my loop?
It looks like you are using this to call the most specific overload (not override) of DevisePlans for the tile provided. Assuming my understanding is correct (please do tell me if I'm wrong), then just use dynamic - it has an inbuilt cache and is optimized for this:
return spaces.SelectMany(s =>
(IEnumerable<IPlan>)DevisePlans((dynamic)tile, (dynamic)s)
);
and... that's it!
I would, however, be tempted to look for an answer involving either polymorphism (against ITile) or C# 4.0 variance.
Create an expression tree (start with Expression.Call), compile it, and you'll have a fast delegate. You should cache the delegate based on the type so that you don't compile for the same type multiple times.
Think what you're looking for here is the visitor pattern. Define an ITileVisitor interface with your overload for each type and then ITile has a Visit method which takes the visitor as a parameter. Its the implementation of Visit which will cause the correct Devise overload to be called.
My boss has asked me to look into a calculation engine. Effectively, the user will have a table of data that can have calculations be performed on. They will also be able to build their own calculations based on certain restrictions we enforce (the built calculations will then be stored in the database)
Is it possible to call a specific method in C#, dependent upon what is stored in the database? So if the database says, a calculation should perform a standard deviation. When we get that information from the database, is it then possible to call a standard deviation method that we will have in C#?
I hope this is clear.
Considering the small/known amount of operations which will be executed on your data, I would opt to manually code these operations, based on the data retrieved from the database. For extendability/maintainability, it's best to create a proper design for this instead of using a simple switch statement. I'm guessing the Strategy pattern will suit your needs.
As others stated, you could use reflection, to call the methods as specified in the database. The problem with this approach is the data in your database is strongly linked to the method signatures. This is less maintainable than the first approach, but does allow for great extendability with minimal code adjustments. Another downside is using MethodInfo.Invoke() is rather slow.
If you would opt for reflection, but find the Invoke() approach to be too slow, I can recommend this article by Jon Skeet which explains how to convert a MethodInfo into a delegate instance. This gives a major speed boost. I wrote a generic implementation using expression trees for this recently.
All in all, it seems like option 1 is still the best for your purposes.
Yes, this is possible; it's called reflection and it's a standard C# feature. Many tutorials exist out on the web; here's some pretty simple example code:
using System;
using System.Reflection;
class CallMethodByName
{
string name;
CallMethodByName (string name)
{
this.name = name;
}
public void DisplayName() // method to call by name
{
Console.WriteLine (name); // prove we called it
}
static void Main()
{
// Instantiate this class
CallMethodByName cmbn = new CallMethodByName ("CSO");
// Get the desired method by name: DisplayName
MethodInfo methodInfo =
typeof (CallMethodByName).GetMethod ("DisplayName");
// Use the instance to call the method without arguments
methodInfo.Invoke (cmbn, null);
}
}
http://en.csharp-online.net/CSharp_FAQ:_How_call_a_method_using_a_name_string
You can store operations in DB and use Microsoft.CSharp.CSharpCodeProvider to compile code on-the-fly.
See sample here: Execute code at runtime
Yes, you can do it using Reflection. You could write a class that contains all the operations that user could do and then call its methods dynamically.
public static class UserOperations
{
public static decimal Average(IEnumerable<decimal> source)
{
return source.Average();
}
// Other methods
}
class Program
{
static void Main(string[] args)
{
// The operation retrieved from the db
string operation = "Average";
// The items on which the operations should be performed
decimal[] items = { 22m, 55m, 77m };
object result = typeof(UserOperations).GetMethod(operation).Invoke(null, new object[] { items });
Console.WriteLine(result);
Console.ReadLine();
}
}
I would suggest you implement strategy pattern (http://www.dofactory.com/Patterns/PatternStrategy.aspx)
You can load different strategies (algorithms) for different calculations required.
There is a nice post as well http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx
You can use the switch statement in C# to execute the operation you want depending on the value of your record's field (or scalar) coming from the database. This is OK if you have a small/limited number of supported operations, otherwise of course you could use reflection and the MethodInfo class to invoke a member method by "string name" on a certain class.
A static field in a generic class will have a separate value for each combination of generic parameters. It can therefore be used as a Dictionary<Type, whatever>
Is this better or worse than a static Dictionary<Type, whatever>?
In other words, which of these implementations is more efficient?
public static class MethodGen<TParam> {
public static readonly Action<TParam> Method = CreateMethod();
static Action<TParam> CreateMethod() { /*...*/ }
}
Or,
public static class MethodGen {
static readonly Dictionary<Type, Delegate> methods
= new Dictionary<Type, Delegate>();
public static Action<T> GetMethod<T>() {
//In production code, this would ReaderWriterLock
Delegate method;
if(!methods.TryGetValue(typeof(T), out method)
methods.Add(typeof(t), method = CreateMethod<T>());
return method;
}
static Action<T> CreateMethod<T>() { /*...*/ }
}
In particular, how does the CLR lookup the static fields by generic type parameter?
I like using generic types this way. In particular, I often have private nested generic classes for precisely this purpose.
The main thing I like about it is that it's hard not to get the initialization right this way (in terms of thread safety), given the way type initialization works. The only problem is what to do if initialization fails - occasionally I've resorted to remembering an exception to throw on first necessary access, but that's pretty rare.
I wouldn't like to guess at exactly how the CLR looks up the type via the type arguments, but I'm pretty sure it'll be optimised to heck and back :)
I believe that the generic (first) version would do the dictionary lookup at compile time, and therefore perform better at runtime.
However, it might use more memory.
I haven't profiled it (which is the only way to really answer this question - the difference in performance may be so small as to be meaningless) but I would hazard a guess that the locking is the expensive part. The CLR does do the locking for you - and does so in a way defined by experts in this field! - so I expect if there is a difference, it would be in favour of using the language feature rather than building it yourself with Dictionary + locking.
It doesn't store values for each generic type parameter as much as it really creates (conceptually anyways) N distinct classes - one for each type T that you use it with.