Difference Between Delegate.Invoke and Delegate()

Difference between Delegate.Invoke and Delegate()

The delTest() form is a compiler helper, underneath it is really a call to Invoke().

Any difference is there Invoke Method (Delegate) and direct call?

They are 100% identical - this is pure compiler sugar (see below). As for which is preferred: neither / both.

static class Program {

    static void Main()
    {
        method1 objDel2;
        objDel2 = new method1(TestMethod1);
        objDel2("test");
        objDel2.Invoke("Invoke");
    }
    delegate void method1(string val);
    static void TestMethod1(string val) {
        System.Console.WriteLine(val);
    }
}

has the IL

.method private hidebysig static void Main() cil managed
{
    .entrypoint
    .maxstack 2
    .locals init (
        [0] class Program/method1 'method')
    L_0000: ldnull 
    L_0001: ldftn void Program::TestMethod1(string)
    L_0007: newobj instance void Program/method1::.ctor(object, native int)
    L_000c: stloc.0 
    L_000d: ldloc.0 
    L_000e: ldstr "test"
    L_0013: callvirt instance void Program/method1::Invoke(string) ***HERE***
    L_0018: ldloc.0 
    L_0019: ldstr "Invoke"
    L_001e: callvirt instance void Program/method1::Invoke(string) ***HERE***
    L_0023: ret 
}

Note both do the same thing (see the two locations marked by me as ***HERE***)

Invoke(Delegate)

The answer to this question lies in how C# Controls work

Controls in Windows Forms are bound to a specific thread and are not
thread safe. Therefore, if you are calling a control's method from a
different thread, you must use one of the control's invoke methods to
marshal the call to the proper thread. This property can be used to
determine if you must call an invoke method, which can be useful if
you do not know what thread owns a control.

From Control.InvokeRequired

Effectively, what Invoke does is ensure that the code you are calling occurs on the thread that the control "lives on" effectively preventing cross threaded exceptions.

From a historical perspective, in .Net 1.1, this was actually allowed. What it meant is that you could try and execute code on the "GUI" thread from any background thread and this would mostly work. Sometimes it would just cause your app to exit because you were effectively interrupting the GUI thread while it was doing something else. This is the Cross Threaded Exception - imagine trying to update a TextBox while the GUI is painting something else.

• Which action takes priority?
• Is it even possible for both to happen at once?
• What happens to all of the other commands the GUI needs to run?

Effectively, you are interrupting a queue, which can have lots of unforeseen consequences. Invoke is effectively the "polite" way of getting what you want to do into that queue, and this rule was enforced from .Net 2.0 onward via a thrown InvalidOperationException.

To understand what is actually going on behind the scenes, and what is meant by "GUI Thread", it's useful to understand what a Message Pump or Message Loop is.

This is actually already answered in the question "What is a Message Pump" and is recommended reading for understanding the actual mechanism that you are tying into when interacting with controls.

Other reading you may find useful includes:

What's up with Begin Invoke

One of the cardinal rules of Windows GUI programming is that only the
thread that created a control can access and/or modify its contents
(except for a few documented exceptions). Try doing it from any other
thread and you'll get unpredictable behavior ranging from deadlock, to
exceptions to a half updated UI. The right way then to update a
control from another thread is to post an appropriate message to the
application message queue. When the message pump gets around to
executing that message, the control will get updated, on the same
thread that created it (remember, the message pump runs on the main
thread).

and, for a more code heavy overview with a representative sample:

Invalid Cross-thread Operations

// the canonical form (C# consumer)

public delegate void ControlStringConsumer(Control control, string text);  // defines a delegate type

public void SetText(Control control, string text) {
    if (control.InvokeRequired) {
        control.Invoke(new ControlStringConsumer(SetText), new object[]{control, text});  // invoking itself
    } else {
        control.Text=text;      // the "functional part", executing only on the main thread
    }
}

Once you have an appreciation for InvokeRequired, you may wish to consider using an extension method for wrapping these calls up. This is ably covered in the Stack Overflow question Cleaning Up Code Littered with Invoke Required.

There is also a further write up of what happened historically that may be of interest.

Difference Between Invoke and DynamicInvoke

When you have a delegate instance, you might know the exact type, or you might just know that it is a Delegate. If you know the exact type, you can use Invoke, which is very fast - everything is already pre-validated. For example:

Func<int,int> twice = x => x * 2;
int i = 3;
int j = twice.Invoke(i);
// or just:
int j = twice(i);

However! If you just know that it is Delegate, it has to resolve the parameters etc manually - this might involve unboxing, etc - a lot of reflection is going on. For example:

Delegate slowTwice = twice; // this is still the same delegate instance
object[] args = { i };
object result = slowTwice.DynamicInvoke(args);

Note I've written the args long hand to make it clear that an object[] is involved. There are lots of extra costs here:

• the array
• validating the passed arguments are a "fit" for the actual MethodInfo
• unboxing etc as necessary
• reflection-invoke
• then the caller needs to do something to process the return value

Basically, avoid DynamicInvoke when-ever you can. Invoke is always preferable, unless all you have is a Delegate and an object[].

For a performance comparison, the following in release mode outside of the debugger (a console exe) prints:

Invoke: 19ms
DynamicInvoke: 3813ms

Code:

Func<int,int> twice = x => x * 2;
const int LOOP = 5000000; // 5M
var watch = Stopwatch.StartNew();
for (int i = 0; i < LOOP; i++)
{
    twice.Invoke(3);
}
watch.Stop();
Console.WriteLine("Invoke: {0}ms", watch.ElapsedMilliseconds);
watch = Stopwatch.StartNew();
for (int i = 0; i < LOOP; i++)
{
    twice.DynamicInvoke(3);
}
watch.Stop();
Console.WriteLine("DynamicInvoke: {0}ms", watch.ElapsedMilliseconds);

What is the difference between [Delegate].DynamicInvoke and [Delegate].Method.Invoke?

DynamicInvoke isn't performed asynchronously, it's dynamic because your parameters that you pass it to the function checking (and unboxing) in the runtime.Invoke requires exact type of parameters but DynamicInvoke requires an object array which contains your parameters. So you can use DynamicInvoke when you don't know exactly type of the parameter.

Here is full (and better :) explanation about it: Difference Between Invoke and DynamicInvoke

Delegate DynamicInvoke vs MethodInfo invoke?

Curiosity did get the better of me so I ended up benchmarking it myself. I still recommend doing it yourself to give it a go and see if you get the same results. If you had a specific situation in mind that might yield different results.

Results

I was kind of surprised at first, but here they are. I added in a standard Delegate.Invoke just to compare.

person.FirstName = "Kevin"; // person is a shared reference
person.LastName = "Spacey";
control.BeginInvoke(UpdateName);
person.FirstName = "Keyser";
person.LastName = "Soze";