Commentaires sur : Optimisation des invocations dynamiques de méthodes en C#

Par : Romain Verdier

Romain Verdier — Mon, 16 Jun 2008 10:50:18 +0000

Il me fallait un exemple :) Celui choisi pour l’article sert juste de support ; il est évident que le vrai problème n’est pas de savoir comment tester la valeur par défaut d’un type.

Si on ajoute le test sur les nullables, ta méthode fonctionne et a pour elle d’être concise. C’est probablement celle que j’aurais utilisée.

Une seule (petite) remarque cependant : le mot clé default repose sur l’opération initobj en CIL, ce qui le rend plus performant qu’une instanciation dynamique via la méthode CreateInstance. Lorsqu’on est dans un contexte générique, ou qu’on connait le type de l’objet, autant l’utiliser…

Par : simon mourier

simon mourier — Mon, 16 Jun 2008 10:20:42 +0000

Au delà de l’aspect pédagogique de l’article :-), on peut aller plus vite je pense:

public bool IsDefaultValue(Type type, object value)
{
if (type == null)
throw new ArgumentNullException(”type”);

if (!type.IsValueType)
return (value == null);

if (value == null)
return false;

return ((ValueType)value).Equals(Activator.CreateInstance(type));
}

Par : Continuer l’optimisation avec la Lightweight Code Generation (LCG) « Codingly

Wed, 07 May 2008 18:31:55 +0000

[...] Publié dans Articles by Romain Verdier sur mai 6th, 2008 Cet article est un complément du précédent. Vous pouviez y lire dans la conclusion : Nous nous sommes contentés d’évoquer la solution [...]

Par : grozeille

grozeille — Mon, 05 May 2008 20:56:25 +0000

Euh…fait un tour sur copine de geek pour avoir des conseils sur comment nous supporter :)
CreateDelegate est aussi utilisé pour appeler des méthodes en “PInvoke dynamique”.
Merci pour l’astuce de la Memoization, c’est malin et j’y ai jamais pensé. En même temps, j’en ai jamais vraiment eux besoin…
En tout cas, on invente rien: soit on re-calcule toujours tout (réflection, etc.) soit on le mémorise. Comme tu le dis, c’est le dilemme CPU vs Mémoire. Et si on peut gagner 30% de perf en utilisant très peu de mémoire en plus…

Par : safia

safia — Mon, 05 May 2008 20:31:57 +0000

Vous êtes des geeks.

Par : Romain Verdier

Romain Verdier — Mon, 05 May 2008 11:04:51 +0000

La solution à base de LCG était juste citée pour qu’on garde en tête qu’il s’agit d’une des techniques d’optimisation possible lorsqu’on fait appel à la réflexion. Dans l’exemple de l’article, il n’est pas judicieux de l’utiliser puisqu’elle nécessite toutes les étapes requises par la seconde solution. En gros, celle qui est décrite dans l’article peut-être résumée de la façon suivante :

1. Appel à GetMethod pour récupérer les infos de la méthode générique
2. Appel à MakeGenericMethod pour récupérer les infos de la méthode générique fermée
3. Creation d’un délégué via l’appel à CreateDelegate sur la classe statique Delegate.

Celle qui implique la LCG reprend les 2 premières étapes, puis ajoute :

3. Création d’une DynamicMethod et génération de son corps en faisant référence au MethodInfo récupéré à l’étape 2.
4. Creation d’un délégué via l’appel à CreateDelegate sur la classe statique DynamicMethod.

La génération d’une méthode dynamique est ici inutile, puisqu’il n’y a qu’une invocation de méthode à faire. la LCG devient utile dans des scénarios plus complexes. Je vais essayer de faire un petit post à ce sujet.

Par : grozeille

grozeille — Sat, 03 May 2008 21:15:00 +0000

La première solution (Utiliser la Lightweight Code Generation (LCG) via Reflection.Emit) m’intéresse.
Si t’as un autre exemple dans un prochain poste…