Quelle est la différence entre un appel un délégué directement, à l'aide de DynamicInvoke, et à l'aide de DynamicInvokeImpl?

Les docs pour les deux DynamicInvoke et DynamicInvokeImpl dire:

Dynamiquement invoque (tardive) de la
méthode représentée par le courant
délégué.

Je remarque que DynamicInvoke et DynamicInvokeImpl prendre un tableau d'objets au lieu d'une liste d'arguments (qui est la tardive de la partie je suppose). Mais est-ce la seule différence? Et quelle est la différence entre DynamicInvoke et DynamicInvokeImpl.

Ne voulez-vous pas accepter une réponse ici? Je sais que la question est assez vieux maintenant, mais j'ai été irritée qu'il n'y a toujours pas de réponse a accepté alors qu'il existe de bons candidats.

InformationsquelleAutor Jason Baker | 2009-05-31

c#delegates

La principale différence entre l'appelant directement (ce qui est à court de main pour Invoke(...)) et à l'aide de DynamicInvoke est de la performance, un facteur de plus de *700 par ma mesure (ci-dessous).

Avec l'direct/Invoke approche, les arguments sont déjà pré-validé par la signature de la méthode, et le code existe déjà à passer à celles de la méthode directement (je dirais "qu'IL", mais il me semble que le runtime fournit directement, sans tout IL). Avec DynamicInvoke il a besoin de les vérifier à partir de la matrice par la réflexion (c'est à dire sont-ils appropriés pour cet appel, ont-ils besoin d'unboxing, etc); c'est lent (si vous l'utilisez dans une boucle), et doit être évitée autant que possible.

Exemple; les résultats de la première (j'ai augmenté la LOOP compter de la précédente édition, pour donner un bon de comparaison):

Direct: 53ms
Invoke: 53ms
DynamicInvoke (re-use args): 37728ms
DynamicInvoke (per-cal args): 39911ms

Avec le code:

static void DoesNothing(int a, string b, float? c) { }
static void Main() {
Action<int, string, float?> method = DoesNothing;
int a = 23;
string b = "abc";
float? c = null;
const int LOOP = 5000000;
Stopwatch watch = Stopwatch.StartNew();
for (int i = 0; i < LOOP; i++) {
method(a, b, c);
}
watch.Stop();
Console.WriteLine("Direct: " + watch.ElapsedMilliseconds + "ms");
watch = Stopwatch.StartNew();
for (int i = 0; i < LOOP; i++) {
method.Invoke(a, b, c);
}
watch.Stop();
Console.WriteLine("Invoke: " + watch.ElapsedMilliseconds + "ms");
object[] args = new object[] { a, b, c };
watch = Stopwatch.StartNew();
for (int i = 0; i < LOOP; i++) {
method.DynamicInvoke(args);
}
watch.Stop();
Console.WriteLine("DynamicInvoke (re-use args): "
+ watch.ElapsedMilliseconds + "ms");
watch = Stopwatch.StartNew();
for (int i = 0; i < LOOP; i++) {
method.DynamicInvoke(a,b,c);
}
watch.Stop();
Console.WriteLine("DynamicInvoke (per-cal args): "
+ watch.ElapsedMilliseconds + "ms");
}

InformationsquelleAutor Marc Gravell

Par coïncidence, j'ai trouvé une autre différence.

Si Invoke déclenche une exception il peut être pris par le type d'exception.
Cependant DynamicInvoke jette un TargetInvokationException. Voici une petite démo:

using System;
using System.Collections.Generic;
namespace DynamicInvokeVsInvoke
{
public class StrategiesProvider
{
private readonly Dictionary<StrategyTypes, Action> strategies;
public StrategiesProvider()
{
strategies = new Dictionary<StrategyTypes, Action>
{
{StrategyTypes.NoWay, () => { throw new NotSupportedException(); }}
//more strategies...
};
}
public void CallStrategyWithDynamicInvoke(StrategyTypes strategyType)
{
strategies[strategyType].DynamicInvoke();
}
public void CallStrategyWithInvoke(StrategyTypes strategyType)
{
strategies[strategyType].Invoke();
}
}
public enum StrategyTypes
{
NoWay = 0,
ThisWay,
ThatWay
}
}

Tandis que le second test passe au vert, le premier est confronté à un TargetInvokationException.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using SharpTestsEx;
namespace DynamicInvokeVsInvoke.Tests
{
[TestClass]
public class DynamicInvokeVsInvokeTests
{
[TestMethod]
public void Call_strategy_with_dynamic_invoke_can_be_catched()
{
bool catched = false;
try
{
new StrategiesProvider().CallStrategyWithDynamicInvoke(StrategyTypes.NoWay);
}
catch(NotSupportedException exc)
{
/* Fails because the NotSupportedException is wrapped
* inside a TargetInvokationException! */
catched = true;
}
catched.Should().Be(true);
}
[TestMethod]
public void Call_strategy_with_invoke_can_be_catched()
{
bool catched = false;
try
{
new StrategiesProvider().CallStrategyWithInvoke(StrategyTypes.NoWay);
}
catch(NotSupportedException exc)
{
catched = true;
}
catched.Should().Be(true);
}
}
}

InformationsquelleAutor Rainer Hilmer

9

Il n'y a vraiment aucune différence fonctionnelle entre les deux. si vous tirez la mise en œuvre dans le réflecteur, vous remarquerez que DynamicInvoke appelle juste DynamicInvokeImpl avec le même ensemble d'arguments. Pas une validation supplémentaire est fait et c'est un non-méthode virtuelle, donc il n'y a aucune chance pour que le comportement de l'être changé par une classe dérivée. DynamicInvokeImpl est une méthode virtuelle où tout le travail est fait.
- Donc, en d'autres termes, DynamicInvoke se réfère toujours à la base du comportement et DynamicInvokeImpl peut être remplacé?
- exactement
InformationsquelleAutor JaredPar

Vous devez vous connecter pour publier un commentaire.