Je veux parler, bien évidemment, de TypedReference. Je vous propose de découvrir ce type à partir d’un exemple rigolo.

Méthodes varargs et interopérabilité

En C#, lorsqu’on veut définir une méthode à nombre de paramètres variables, on utilise la syntaxe suivante :

public static double Average(params int[] values)
{
    double sum = 0;
    foreach (var i in values)
        sum += i;
    return sum / values.Length;
}

Notez le mot clé params qui permet l’appel de la méthode en passant un tableau en paramètre, ou en listant plus librement les arguments :

var parameters = new int[]{45, 68, 97, 45};
ManagedClass.Average (parameters)
// ou bien
ManagedClass.Average (45, 68, 97, 45)

En C++ / CLI, la syntaxe est un peu différente mais le principe est le même :

double CodinglyInterop::CppCliLibrary::average(... array<int,1> ^values)
{
	double sum = 0;
	for each (int i  in values)
		sum += i;
	return sum/values->Length;
}

C’est pareil, en plus moche. On utilise “...” au lieu de “params“, et l’appelant peut passer un tableau ou une liste d’arguments :

var parameters = new int[]{45, 68, 97, 45};
CppCliLibrary.average(parameters)
// ou bien
CppCliLibrary.average(45, 68, 97, 45)

Notez que l’interopérabilité entre C# et C++/CLI est native : les deux langages sont managés.

Et en C++ pas CLI, qu’est-ce que donnent les fonctions à nombre variable d’arguments ?

Bah c’est encore plus moche, et plus contraignant. Rappelez-vous :

extern "C" __declspec(dllexport) double average(int n, ...)
{
	double sum = 0;
	va_list args;
	va_start(args, n);
	for(int i=0 ;i < n; i++)
		sum += va_arg(args, int);
	va_end(args);
	return sum/n;
}

La principale différence est finalement assez subtile on n’utilise pas explicitement un tableau, mais on fournit un pointeur vers le début de la liste d’arguments. C’est à la méthode de se débrouiller (avec des macros) pour itérer, caster et s’arrêter lorsqu’il le faut. Généralement, un autre paramètre nommé de la méthode contient les infos nécessaires à cette opération. Dans l’exemple précédent, “n” est utilisé pour passer directement le nombre d’arguments de la liste. Dans printf, c’est la format string qui permet à la fonction de savoir combien d’arguments elle doit lire.

La question rigolote, puisque nous sommes dans le contexte d’un exemple rigolo, est la suivante :

Mais comment appeler les fonctions natives de ce genre depuis C# ? En utilisant pinvoke, probablement, mais plus précisément ?

Réponse : En pleurant. On est obligé de déclarer explicitement les imports pour chacune des utilisations que l’on va faire de la fonction dans notre code managé. En gros :

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2, int i3);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2, int i3, int i4);

// Etc.

What a PITA, comme qui dirait… Mais c’est ici que l’ornithorynque nous sauve la vie. Car on peut écrire :

[DllImport ("NativeLibrary.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern double average (int n, __arglist );

Et appeler la fonction ainsi :

NativeWrapper.average (4, __arglist (45, 68, 97, 45))

Hourra, donc. Mais quel est ce mot clé bizarre, __arglist, qui n’est même pas reconnu par Resharper ? Et bien il s’agit d’un des mots clés non documentés du langage, qui permettent principalement de jouer avec les TypedReference. Pour mieux comprendre ce qui se passe, essayons de réécrire en C# la méthode Average, sans utiliser le mot clé params, et en se reposant donc uniquement sur les “références typées”. On s’attaquera ensuite à la définition.

public class ManagedEvil
{
    public static double Average(__arglist)
    {
        double sum = 0;
        int count = 0;
        var iterator = new ArgIterator(__arglist);
        do
        {
            TypedReference typedReference = iterator.GetNextArg();
            sum += __refvalue( typedReference,int);
            count++;
        } while (iterator.GetRemainingCount() > 0);
        return sum / count;
    }
}

On note :

• L’apparition du type ArgIterator, dont on crée une instance à partir de la liste d’arguments.
• L’élément courant retourné par l’itérateur est une référence typée : TypedReference.
• Un nouveau mot clé, __refvalue, permet d’extraire la valeur pointée par la référence.

Et tout ça compile, tout ça fonctionne, même si l’intérêt est limité.

TypedReference, __makeref, __refvalue, __reftype

Arrêtons les expériences pour décortiquer un peu plus sérieusement ce TypedReference. La MSDN définit très clairement la TypedReference :

Describes objects that contain both a managed pointer to a location and a runtime representation of the type that may be stored at that location.

Retenons qu’il s’agit d’une structure contenant :

• Un pointeur managé vers un espace mémoire
• Le type de ce qui est pointé en mémoire

Le meilleur endroit pour trouver des infos au sujet de TypedReference est finalement la spécification ECMA 335 du CIL. Je vous laisse fouiller, mais sachez que les bases sont notamment posées dans le paragraphe suivant (cf. 8.6.1.3):

La signature d’une référence typée est en fait représentée en tant que type valeur de base, comme les entiers ou nombres à virgule flottante. Dans la bibliothèque de classes du framework, le type est représenté par System.TypedReference, tandis que dans le langage intermédiaire il est désigné par le mot clé typedref. Ce type doit uniquement être utilisé pour les paramètres et les variables locales. Il ne peut ni être boxé ni être utilisé pour typer un champ, un élément de tableau, ou une valeur de retour de fonction.

Pour que je ne puisse jamais justifier l’intérêt de cet article, les gens chez Microsoft ont bien fait attention à exposer ce type le moins possible. Il est pourtant assez utilisé en interne, notamment dans System.Array, System.Threading.Interlocked, les services d’intérop (InteropServices) ainsi que dans certains overloads cachés utilisant les varargs (String.Concat, Console.WriteLine). A vrai dire, il semblerait que la raison officielle de son existence soit justement le support par le CLR des listes d’arguments, comme nous l’avons vu plus tôt. Il existe cependant un autre endroit (parmi d’autres) où son utilisation peut s’avérer intéressante : la réflexion via les FieldInfo. Mais avant d’y venir, regardons plutôt comment utiliser, très mécaniquement, TypedReference. On peut soit utiliser les mots clés interdits, soit – lorsque c’est possible – utiliser les quelques méthodes statiques de la classe TypedReference elle-même.

Création d’une référence typée : __makeref

Les références typées peuvent être obtenues pour des variables de n’importe quel type (référence ou valeur) à l’aide du mot clé __makeref.

int i = 42;
TypedReference typedReference = __makeref (i);

Ce mot clé dont l’usage n’est pas documenté correspond à l’instruction mkrefany en CIL. Le code intermédiaire correspondant à l’exemple précédant est le suivant :

int i = 42;

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/

TypedReference typedReference = __makeref(i);

L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

La méthode statique TypedReference.MakeTypedReference permet aussi de créer des références typées, mais pas directement à partir d’une variable. Nous verrons un exemple d’utilisation dans la dernière partie de l’article.

Récupérer et/ou modifier la valeur : __refvalue

Une fois qu’on a une référence typée, il est possible de lire et/ou d’écrire la valeur référencée en utilisant le mot clé __refvalue. Il est visuellement assimilable à un appel de fonction à deux paramètres, dont le premier serait la TypedReference, et le second le type de la valeur référencée. En l’utilisant à droite d’une affectation, on lit la valeur, et en l’utilisant à gauche d’une affectation, on écrit la valeur. Assez troublant…

int i = 42;
TypedReference typedReference = __makeref(i);
int j = __refvalue (typedReference, int);
__refvalue (typedReference, int) = 24;

Encore une fois, il est possible de mapper son utilisation avec un opcode spécifique, refanyval :

int i = 42;
TypedReference typedReference = __makeref(i);

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/
L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

int j = __refvalue (typedReference, int);

L_000b: ldloc.1			/* push sur la pile de la typedReference				*/
L_000c: refanyval int32 /* push sur la pile de l'adresse de la référence        */
L_0011: ldind.i4		/* déréférencement et push sur la pile de la valeur		*/
L_0012: stloc.2			/* sauvegarde dans la variable locale j					*/

__refvalue (typedReference, int) = 24;

L_0013: ldloc.1			/* push sur la pile de la typedReference				*/
L_0014: refanyval int32 /* push sur la pile de l'adresse de la référence        */ 
L_0019: ldc.i4.s 0x18	/* push sur la pile d'un int32 = 24						*/
L_001b: stind.i4		/* sauvegarde de la valeur à l'adresse de la référence  */

La méthode TypedReference.ToObject permet aussi de déréférencer la TypedReference et d’obtenir sa valeur, boxée.

Récupérer le type : __reftype

Enfin, il est possible de récupérer l’information de type associée à la TypeReference, en utilisant un dernier mot clé __reftype.

int i = 42;
TypedReference typedReference = __makeref(i);
Type type = __reftype(typedReference);

Là encore, on peut faire correspondre __reftype à l’opcode refanytype :

int i = 42;
TypedReference typedReference = __makeref(i);

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/
L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

Type type = __reftype(typedReference);

L_000b: ldloc.1			/* push sur la pile de la typedReference				*/
L_000c: refanytype		/* push sur la pile du type token de la référence		*/
L_000e: call class Type::GetTypeFromHandle(RuntimeTypeHandle)
L_0013: stloc.2			/* récupération et sauvegarde du Type à partir du token */

Notons que la méthode statique TypedReference.GetTargetType est l’équivalent autorisé de __reftype, et qu’il existe aussi la méthode TypedReference.TargetTypeToken qui retourne le handle du type sous la forme d’un RuntimeTypeHandle. La version light, en somme.

Rien de très impressionnant ; d’ailleurs vous pouvez retourner sur youtube car la suite n’est pas mieux. Mais je persiste !

Un autre exemple : GetValueDirect et SetValueDirect

Je vous disais tout à l’heure que j’avais trouvé un exemple d’utilisation dans lequel on pouvait faire intervenir les TypedReference. Il s’agit de la lecture écriture des champs par réflexion, et plus particulièrement des champs de type valeur. Et encore plus particulièrement lorsqu’ils sont imbriqués.

Prenons pour exemple ce modèle simpliste :

public struct Person
{
	public Address Address;
}

public struct Address
{
	public City City;
}

public struct City
{
	public int ZipCode;
}

Il est important de bien noter que Person, Address, City et ZipCode sont des value types. Si on veut inspecter une instance de Person par réflexion, jusqu’à lire le ZipCode de son adresse, on va écrire quelque chose comme :

// On a une instance de Person
var p = new Person();
p.Address.City.ZipCode = 75000;

// On récupère les FieldInfo
var addressField = typeof(Person).GetField("Address");
var cityField = typeof(Address).GetField("City");
var zipCodeField = typeof(City).GetField("ZipCode");

// On chaine les appels à FieldInfo.GetValue pour inspecter la Person
// et lire la valeur du ZipCode
var zipCode =  (int)zipCodeField.GetValue(cityField.GetValue(addressField.GetValue(p)));

Ca fonctionne, mais le boxing a tué mon hourra. GetValue prend un object en argument, et retourne un object, alors qu’on travaille ici sur des types valeurs… En lisant la dernière ligne de droite à gauche :

• p va être boxé pour être passé en paramètre à GetValue
• addressField.GetValue va boxer la valeur du champ Address pour le retourner sous la forme d’un object
• cityField.GetValue va boxer la valeur du champ City pour le retourner sous la forme d’un object
• zipCodeField.GetValue va boxer la valeur du champ ZipCode pour le retourner sous la forme d’un object
• Le cast en int effectue l’ultime et nécessaire unboxing

Pas terrible…

Heureusement, il existe sur FieldInfo la méthode GetValueDirect, qui prend en paramètre une TypedReference !

Si on peut directement récupérer une référence typée sur le ZipCode, on peut éviter quelques emboitages :

var p = new Person();
p.Address.City.ZipCode = 75000;
FieldInfo zipCodeField = typeof(City).GetField("ZipCode");
var zipCode = (int)zipCodeField.GetValueDirect(__makeref (p.Address.City)); 

Seulement, on change les contraintes, car la création de la référence typée de cette façon implique alors que l’on connaisse Address et City au design time. Qu’à cela ne tienne : il existe la méthode statique TypedReference.MakeTypedReference évoquée plus tôt, qui permet de construire une référence typée à partir d’une target et d’un tableau de FieldInfo correspondant à l’inspection désirée de l’espace mémoire réservé par p :

var p = new Person ();
p.Address.City.ZipCode = 75000;
var addressField = typeof (Person).GetField ("Address");
var cityField = typeof (Address).GetField ("City");
var zipCodeField = typeof (City).GetField ("ZipCode");

TypedReference r = TypedReference.MakeTypedReference (p, new[] {addressField, cityField});
var zipCode = (int) zipCodeField.GetValueDirect (r);

Dans ce cas précis, les performances mesurées sont environ 4 fois meilleures en utilisant GetValueDirect à la place de GetValue. Hourra.

Quant à l’écriture, nous n’avons même pas le luxe du choix, puisque chainer les SetValue ne peut en aucun cas modifier la personne, cette fonction retournant à chaque fois une copie des valeurs… Il faut donc nécessairement utiliser SetValueDirect et une TypedReference.

Conclusion

La conclusion, que je vous dois brève :

Ce qui n’est pas documenté ne doit pas être utilisé. En gros, tout ce qui est lié aux arglists est à oublier. En revanche, la création et la manipulation de TypedReference sans passer par tous les __mots __clés __moches n’est pas réprouvée. Notez simplement que TypedReference n’est pas CLS Compliant.

Nous nous sommes contentés d’évoquer la solution d’optimisation impliquant la génération de code IL. Dans le contexte de la problématique discutée, elle n’offrait aucun avantage par rapport à celle que nous avons exposée. Pire, elle imposait une étape inutile. Toutefois, certains besoins plus complexes dépassent le cadre des invocations dynamiques de méthodes et peuvent tout de même être adressés efficacement en recourant à la génération de bytecode.

S’il existe des scénarios dans lesquels le recourt à la LCG est inutile voire pénalisant, il n’y a parfois aucune autre alternative lorsqu’il s’agit de mettre en place une solution où les performances sont aussi importantes que la dynamicité.

Vous ne trouverez pas ici un tutorial sur l’utilisation de Reflection.Emit, mais plutôt un exemple d’utilisation de cette technique pour répondre de façon optimale à un besoin bien spécifique. Nous essaierons en parallèle de faire ressortir quelques guidelines relatives à l’usage de la LCG.

Mais c’est quoi, ce truc ?

La LCG, ou Lightweight Code Generation, fait référence à une nouveauté apparue dans la seconde version du Framework .NET.

Il a toujours été possible en .NET d’utiliser l’API du namespace System.Reflection.Emit pour générer des assemblies, des modules et des types dynamiquement. Le principe est simple : on autorise via cette API les développeurs de la plateforme .NET à produire directement du code intermédiaire. C’est extrêmement puissant, mais très rapidement complexe. Le fait que le CIL ainsi obtenu soit (quasiment) impossible à débuguer ne vient pas arranger les choses.

C’était en quelque sorte la Heavyweight Code Generation : pour générer dynamiquement le bytecode correspondant à un traitement, il fallait la plupart du temps se taper la création d’un assembly, d’un module et d’un type pour finalement héberger la méthode encapsulant l’opération. Tout cela est souvent nécessaire, mais le reste du temps, c’est juste lourd.

Typiquement, lorsqu’on utilise la génération de CIL pour créer un proxy dynamiquement, on veut définir un type complet avec ses membres et ses méthodes. En revanche, pour créer une simple méthode au runtime on préfèrerait s’en passer.

La LCG autorise justement la création de méthodes dynamiques pouvant être réclamées par le garbage collector, et surtout ayant la capacité d’être hébergées anonymement, sans que l’on ait à créer d’assembly, de module ou de type. Outre le fait que de telles méthodes soient relativement faciles à créer (je ne parle pas de la génération de leurs corps), elles peuvent également être invoquées via des délégués. Et ça on connait, c’est efficace.

Parfois, c’est inutile

Dans l’article précédent, nous avons vu comment il était possible de créer un délégué pointant sur un MethodInfo pour considérablement optimiser les invocations dynamiques. L’exemple s’y prêtait bien : nous connaissions la signature de la méthode à appeler dynamiquement donc nous pouvions :

• Définir un type de délégué correspondant
• Solliciter la méthode CreateDelegate de la classe Delegate
• Invoquer le délégué ainsi récupéré

C’est vraiment ce qu’il faut retenir. Il n’y a aucune raison d’utiliser la LCG si les signatures des méthodes à appeler dynamiquement sont connues et qu’il est possible de définir les délégués correspondants.

Un exemple moins ingrat

Vous aurez compris que lorsque la signature des méthodes à appeler dynamiquement n’est pas connue durant le design, il est impossible de déclarer un délégué correspondant à la méthode que l’on veut appeler. Il en découle que l’invocation via délégué est à oublier, et qu’il ne reste donc que la bonne vieille méthode Invoke sur le MethodInfo.

Oui, celle-la même qui ruine les performances.

A l’origine, je voulais trouver un exemple ni trop idiot ni trop complexe pour mettre ce cas en évidence et introduire la LCG. Finalement, je n’ai pas été capable de trouver quelque chose respectant cet équilibre. Vous aurez donc droit à un exemple vraiment simple et super idiot : le cloneur.

Commençons par en définir l’interface :

public interface ICloner
{
    object Clone(object toClone);
}

Les types respectant ce contrat devront fournir via la méthode Clone un service capable de retourner un shallow clone de l’objet passé en paramètre. Pour simplifier ici, nous ne considèrerons que les propriétés publiques des objets.

Ecrivons directement un test unitaire :

[Test]
public void Test()
{
    var cloner = GetCloner();
    var p = new Person
            {
               Id = 1,
               Firstname = "Romain",
               Lastname = "Verdier",
               BirthDate = new DateTime(1976, 03, 02),
               Height = 1.65
            };
    var p2 = cloner.Clone(p) as Person;
    Assert.AreNotEqual(p,p2);
    Assert.AreEqual(p.Id, p2.Id);
    Assert.AreEqual(p.Firstname, p2.Firstname);
    Assert.AreEqual(p.Lastname, p2.Lastname);
    Assert.AreEqual(p.BirthDate, p2.BirthDate);
    Assert.AreEqual(p.Height, p2.Height);
}

En utilisant simplement la réflexion, on peut proposer l’implémentation non optimisée suivante :

public class Cloner : ICloner
{
    private readonly Func<Type, Func<object, object>> clonerLocator;

    public Cloner()
    {
        this.clonerLocator = ((Func<Type, Func<object, object>>)GetCloner).Memoize();
    }

    public object Clone(object toClone)
    {
        var cloner = this.clonerLocator(toClone.GetType());
        return cloner(toClone);
    }

    private Func<object, object> GetCloner(Type type)
    {
        var constructorInfo = type.GetConstructor(Type.EmptyTypes);
        if (constructorInfo == null)
        {
            throw new ArgumentException(string.Format("'{0}' type doesn't have a default constructor.", type.Name));
        }

        return toClone =>
        {
            var clone = Activator.CreateInstance(type);
            var propertyInfos = type.GetProperties(BindingFlags.Instance | BindingFlags.Public);
            foreach (var propertyInfo in propertyInfos)
            {
                var setterInfo = propertyInfo.GetSetMethod();
                var getterInfo = propertyInfo.GetGetMethod();
                if (setterInfo != null && getterInfo != null)
                {
                    // Deux invocations dynamiques ont lieu ici sans que l'on puisse
                    // utiliser de délégués.
                    setterInfo.Invoke(clone, new object[] {getterInfo.Invoke(toClone, null)});
                }
            }
            return clone;
        }
    }
}

Notons à propos du code précédent :

• Peu de vérifications sont faites, c’est à la fois volontaire et mal.
• Nous n’utilisons pas GetValue et SetValue sur les PropertyInfo pour rendre les invocations dynamiques de méthodes explicites : ici, on fait deux invocations dynamiques par propriété. Une sur le getter, et une sur le setter.
• Ne pas connaitre le type de chaque propriété à l’avance signifie que l’on ne connait pas la signature des getters et des setters. Ne pas connaître la signature des getters et des setters nous empêche d’utiliser la méthode décrite dans l’article précédent.
• La memoization et l’utilisation d’un locateur ne servent qu’à faciliter la comparaison que l’on pourra faire avec la prochaine solution, puisqu’on ne peut pas utiliser de caching dans celle-ci.

Puisque vous aimez les chiffres comme tout le monde, j’ai créé un test de performances effectuant un million d’appels à la méthode de clonage. Et houlala, c’est lent : 1000000 appels en plus de 26 secondes.

En utilisant la LCG, il va être possible de générer une méthode encapsulant la logique de clonage relative à un type donné. On pourra également créer un délégué pour cette méthode, afin qu’elle puisse être invoquée sans que les performances ne soient dégradées. Ce délégué – et on rejoint ici le principe d’optimisation commun à toutes les solutions – pourra être mis en cache pour éviter que la méthode dynamique ne soit regénérée systématiquement.

Voyons ce que ça donne :

public class CilCloner : ICloner
{
    private readonly Func<Type, Func<object, object>> clonerLocator;

    public Cloner()
    {
        this.clonerLocator = ((Func<Type, Func<object, object>>) GetCloner).Memoize();
    }

    public object Clone(object toClone)
    {
        var cloner = this.clonerLocator(toClone.GetType());
        return cloner(toClone);
    }

    private Func<object, object> GetCloner(Type type)
    {
        var constructorInfo = type.GetConstructor(Type.EmptyTypes);
        if (constructorInfo == null)
        {
            throw new ArgumentException(string.Format("'{0}' type doesn't have a default constructor.", type.Name));
        }

        var dynamicMethod = new DynamicMethod(string.Format("<{0}>DoClone", type.Name),
                                              typeof (object),
                                              new []{typeof (object)},
                                              this.GetType());

        var propertyInfos = type.GetProperties(BindingFlags.Instance | BindingFlags.Public);

        var gen = dynamicMethod.GetILGenerator();
        var local = gen.DeclareLocal(type);
        gen.Emit(OpCodes.Newobj, constructorInfo);
        gen.Emit(OpCodes.Stloc, local);
        foreach(var propertyInfo in propertyInfos)
        {
            var setterInfo = propertyInfo.GetSetMethod();
            var getterInfo = propertyInfo.GetGetMethod();
            if (setterInfo != null && getterInfo != null)
            {
                gen.Emit(OpCodes.Ldloc, local);
                gen.Emit(OpCodes.Ldarg_0);
                gen.Emit(OpCodes.Callvirt, getterInfo);
                gen.Emit(OpCodes.Callvirt, setterInfo);
            }
        }
        gen.Emit(OpCodes.Ldloc, local);
        gen.Emit(OpCodes.Ret);

        return (Func<object, object>) dynamicMethod.CreateDelegate(typeof (Func<object, object>));
    }
}

Décortiquons une fois de plus la solution, en gardant à l’esprit que le but de l’article n’est pas d’apprendre à coder en CIL :

• Le membre clonerLocator est gardé en champ d’instance afin que l’on puisse le mémoizer.
• Le constructeur s’occupe de cette tâche en faisant appel à la méthode d’extension Memoize dont vous pourrez (re)trouver la définition dans l’article précédent.
• La méthode Clone, correspondant à l’implémentation de l’interface ICloner, se contente de récupérer via le locateur un délégué capable d’effectuer le clone de l’objet passé en paramètre. Elle l’invoque directement ensuite.
• Le cœur de la solution réside donc dans la méthode GetCloner :
  • Une guard clause permet de vérifier si le type de l’objet à créer expose bien un constructeur par défaut.
  • Une DynamicMethod est crée. Il s’agit d’une méthode prenant en paramètre un object et retournant un object, qui sera capable de cloner un objet du type type
  • Grâce à la réflexion, on récupère les métadonnées de toutes les propriétés publiques du type type.
  • On récupère le générateur de code IL de la méthode dynamique afin de pouvoir émettre le corps de cette dernière.
  • On génère le code IL correspondant à la déclaration d’une variable locale de type type. On l’initialise avec une nouvelle instance de type.
  • On itère sur toutes les métadonnées des propriétés, et on ne considère que celles qui sont à la fois accessibles en lecture et en écriture.
  • A chaque fois que cette condition est vérifiée, on produit le code correspondant à l’affectation de la propriété du clone (appel au setter). La valeur utilisée pour l’affectation est celle récupérée par le getter sur la propriété de l’objet à cloner.
  • On termine la construction du corps de la DynamicMethod en émettant les instructions IL correspondant au retour du clone.
  • Enfin, la méthode GetCloner crée un délégué à partir de la méthode dynamique via CreateDelegate, et le renvoit.

C’est beau ! La mesure des performances en utilisant le même test que précédemment indique cette fois qu’un million de clones ont été créés en 305 ms. Pour information, la méthode MemberwiseClone donne un résultat de 234 ms.

Conclusion

La Lightweight Code Generation, et plus globalement l’utilisation de Reflection.Emit, permet d’apporter des solutions insoupçonnées à certains problèmes bien spécifiques. Cependant, elle n’est pas gratuite et demande un investissement non négligeable de la part de ceux qui veulent la maitriser ou bien même s’en servir ponctuellement. Les développements peuvent être nettement ralentis tandis que les phases de debug et de maintenance risquent de devenir critiques.

Il est donc surtout important de :

• Savoir que la technique existe.
• Savoir reconnaitre les scénarios qui rendent son emploi envisageable.

Il existe assez peu de bonnes ressources permettant d’apprendre à maitriser cette technique. Je suis en train de lire CIL Programming: Under the Hood of .NET de Jason Bock, sans être spécialement séduit. Je conseille aux plus curieux de commencer par la MSDN et Google, puis de consulter les sources de projets qui utilisent l’émission de bytecode. Le blog de Jean-Baptiste Evain est également riche en infos au sujet du CIL : il est l’auteur entre autres de Mono.Cecil.

Mais j’y reviendrai.

Travailler sur un projet d’une certaine taille ne signifie pas forcément que l’on travaille sur un projet intéressant, mais ça augmente sensiblement les chances de rencontrer de nouveaux problèmes. Il n’est pas question aujourd’hui de définir ce qu’est un projet d’une certaine taille, ni même de démontrer le postulat précédent ; il s’agit plutôt de parler d’une des dernières problématiques auxquelles j’ai dû faire face :

Comment éviter que les invocations dynamiques de méthodes via la réflexion rendent les performances d’une application ou d’un module catastrophiques ?

Réponse : En minimisant l’utilisation de la réflexion. C’est ce que je vais tenter de développer à travers un exemple directement inspiré du projet réel, quoiqu’adapté pour les besoins de l’article. Le langage utilisé sera C# 3.0, mais rien n’empêche d’utiliser C# 2.0.

Invocation dynamique de méthodes

Le langage C# supporte la réflexion. Dès lors il est envisageable d’appeler dynamiquement des méthodes. La puissance de ce mécanisme est souvent contrebalancée par son coût. Prenons un exemple basique :

public void CallMethod(object target, string methodName)
{
    Type type = target.GetType();
    MethodInfo methodInfo = type.GetMethod(methodName);
    if (methodInfo != null)
    {
        methodInfo.Invoke(target, null);
    }
}

La fonction précédente est capable d’exécuter une méthode (sans valeur de retour ni paramètre) à partir de son nom, sur un objet donné. Cette implémentation est un désastre mais là n’est pas le vrai problème. Le vrai problème est inhérent aux performances. Essayons de nous concentrer sur ce qui coûte :

• L’appel à GetType pour récupérer le type de l’objet ne coûte quasiment rien. Nous pouvons considérer que la durée de son exécution est négligeable.
• L’appel à GetMethod pour récupérer les métadonnées relatives à la méthode peut également être ignoré. Attention toutefois : le coût peut ici varier en fonction de la surcharge choisie pour GetMethod, et du type sur lequel on l’appelle.
• L’appel à Invoke pour exécuter dynamiquement la méthode prend beaucoup de temps. En fait, c’est ce qui est le plus coûteux. Dans un simple test consistant à invoquer dynamiquement la méthode Clone sur une chaine de caractères, la durée d’exécution s’est avérée être plus de 400 fois supérieure à celle nécessaire à un appel classique.

Mais relativisons. Si vous êtes dans un scénario impliquant une seule invocation dynamique, vous n’allez sans doute jamais avoir à vous préoccuper des performances. Qu’un appel de méthode vous coûte 2 microsecondes au lieu de 4 nanosecondes n’est pas forcément dramatique ; en vérité, ça l’est rarement dans la plupart des applications.

Les scénarios critiques sont ceux qui vous forcent à utiliser la réflexion et l’invocation dynamique pour des tâches cruciales et récurrentes. Les petites microsecondes font les grandes décennies, etc.

Essayons donc de se mettre en situation en prenant un exemple un peu plus sérieux.

Il nous faut la réflexion

Admettons que le rôle d’un module clé de notre application soit de traiter un flux de données ; ces données étant des DTO quelconques. Une des tâches du module consiste à inspecter les propriétés de ces objets, ou plus précisément, à déterminer si la valeur courante de chaque propriété correspond à la valeur par défaut du type de la propriété.

Un test unitaire vaut 1000 mots. Voici celui qui valide (presque) le fonctionnement d’un composant capable d’effectuer la vérification dont nous venons de parler :

[Test]
public void ShouldBeAbleToFindDefaultValues()
{
    IDefaultValueTester tester = CreateDefaultValueTester();

    Assert.IsFalse(tester.IsDefaultValue(typeof(int), 12));
    Assert.IsTrue(tester.IsDefaultValue(typeof(int), 0));
    Assert.IsTrue(tester.IsDefaultValue(typeof(double?), null));
    Assert.IsTrue(tester.IsDefaultValue(typeof(string), null));
    Assert.IsFalse(tester.IsDefaultValue(typeof(string), "test"));
    Assert.IsFalse(tester.IsDefaultValue(typeof(DateTime), DateTime.Now));
    Assert.IsTrue(tester.IsDefaultValue(typeof(DateTime), new DateTime()));
}

L’interface IDefaultValueTester est simple :

public interface IDefaultValueTester
{
    bool IsDefaultValue(Type type, object value);
}

L’objet de cet article n’est pas vraiment de trouver un moyen de faire passer ce test. Il existe d’ailleurs une solution évidente, bien que peu élégante, qui consisterait à utiliser un switch-like. Mais il ne faut pas oublier qu’en .NET, un type peut être :

• Un type référence : class, interface.
• Un type valeur : type de base (int, double, bool, etc.), enum, struct.
• Un type nullable : implémentation de la classe générique Nullable<T> (int?, double?, bool?, etc.)

Dès lors, il est assez facile d’imaginer que le switch sera immonde, et pas forcément performant puisqu’il faudrait dans certains cas – je pense aux structures – instancier des objets “templates” servant de base aux comparaisons.

J’ai pensé à une solution différente, basée sur les generics. Il est possible qu’il y ait encore plus malin, mais celle-ci a pour avantage de constituer un bon support pour cet article :

• Elle nécessite que l’on recoure à l’invocation dynamique de méthode.
• Elle est lente, donc bonne candidate à l’optimisation.

Le principe consiste à tirer partie du mot clé default (capable de retourner la valeur par défaut d’un type) que l’on utilise souvent dans le contexte de la généricité. Voyons donc comment l’exploiter pour implémenter le cœur de cette solution :

public static bool IsDefaultValue<T>(object value)
{
    var type = typeof(T);

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

    if (value != null)
        return value.Equals(default(T));

    if (type.IsGenericType && type.GetGenericTypeDefinition() == typeof(Nullable<>))
        return true;

    var message = "The value type '{0}' can't be null.";
    throw new ArgumentException(string.Format(message, type.Name));
}

Tout le monde aura noté la subtile différence qu’il y a entre le prototype de cette méthode et celui de l’unique méthode IsDefaultValue de l’interface IDefaultValueTester : le type qui était passé sous la forme d’un objet de type Type se retrouve à présent en paramètre de type T d’une méthode générique. Et c’est là qu’interviennent la réflexion et l’invocation dynamique de méthode.

Examinons donc l’implémentation de IDefaultValueTester que je propose :

public class DefaultValueTester : IDefaultValueTester
{
    public bool IsDefaultValue(Type type, object value)
    {
        // On récupère les métadonnées de la méthode générique statique
        // IsDefaultValue présente dans la classe courante.
        var thisType = typeof(DefaultValueTester);
        var methodInfo = thisType.GetMethod("IsDefaultValue", 
                                            BindingFlags.Static 
                                            | BindingFlags.Public);

        // On lui spécifie au runtime son paramètre de type générique
        methodInfo = methodInfo.MakeGenericMethod(type);

        // On invoque dynamiquement la méthode générique fermée
        return (bool) methodInfo.Invoke(null, new [] {value});
    }
    
    public static bool IsDefaultValue<T>(object value)
    {
        // cf. extrait de code précédent.
    }
}

La réflexion est donc nécessaire pour spécifier lors de l’exécution le paramètre de type de la méthode générique. Une fois la méthode fermée, on utilise Invoke pour l’exécuter dynamiquement. Résultat : le test passe.

Peut-on optimiser ?

Oui, et heureusement. Car si on s’en tient à la description du contexte, il serait assez irresponsable d’utiliser ce DefaultValueTester au niveau du composant clé de notre architecture. Rappelons que ce dernier est censé inspecter les propriétés de tous les objets arrivant sur le flux. Si nous considérons qu’il s’agit d’un flux faisant parvenir au module des milliers d’objets par seconde, l’optimisation n’est plus une option.

Voici un nouveau test qui nous permet d’avoir une idée à propos des performances de la solution actuelle :

[Test]
public void Test()
{
    var stopwatch = new Stopwatch();
    const int iterationCount = 100000;
    stopwatch.Start();

    IDefaultValueTester tester = CreateDefaultValueTester();
    for (var i = 0; i < iterationCount; i++)
    {
        tester.IsDefaultValue(typeof(int), 12);
        tester.IsDefaultValue(typeof(int), 0);
        tester.IsDefaultValue(typeof(double?), null);
        tester.IsDefaultValue(typeof(string), null);
        tester.IsDefaultValue(typeof(string), "test");
        tester.IsDefaultValue(typeof(DateTime), DateTime.Now);
        tester.IsDefaultValue(typeof(DateTime), new DateTime());
    }

    stopwatch.Stop();
    Console.WriteLine(string.Format("{0} iteration(s) in {1} ms.", 
                                    iterationCount, 
                                    stopwatch.ElapsedMilliseconds));
}

Les 100000 itérations ont été effectuées en 10625 ms. C’est loin d’être terrible.

Il existe au moins deux façons différentes d’optimiser les invocations dynamiques de méthodes en C# dans un tel scénario. Les deux introduisent la notion de caching et se basent sur les délégués.

1. Première solution :
   • Utiliser la Lightweight Code Generation (LCG) via Reflection.Emit pour générer dynamiquement le code CIL correspondant à l’appel de la méthode générique IsDefaultValue<T> fermée sur le bon type.
   • Utiliser la méthode CreateDelegate de DynamicMethod pour récupérer un délégué pointant sur la méthode que l’on vient de générer.
2. Seconde solution :
   • Conserver l’usage de la réflexion pour fermer le type de la méthode générique (appel à la méthode MakeGenericMethod) et récupérer le MethodInfo correspondant.
   • Utiliser la méthode statique CreateDelegate de la classe abstraite Delegate pour récupérer un délégué à partir du MethodInfo précédent.

Les délégués ainsi obtenus ont deux particularités qui les rendent précieux dans le contexte de cette optimisation :

• Le coût de leur invocation est quasiment nul, contrairement à l’appel à la méthode Invoke sur un MethodInfo.
• Ils peuvent être mis en cache, et indexés intelligemment de façon à ce qu’ils ne soient pas recréés à chaque fois. Ici, il suffit d’utiliser le type des propriétés comme clé.

Retenons ici la seconde solution, qui est plus simple à développer, maintenir et tester, et voyons ce que cela donne :

using TesterMethodDelegate = Func<object, bool>;

public class OptimizedDefaultValueTester : IDefaultValueTester
{
    private readonly Dictionary<Type, TesterMethodDelegate> cache = new Dictionary<Type, TesterMethodDelegate>();

    public bool IsDefaultValue(Type type, object value)
    {
        var tester = GetTesterMethodDelegate(type, value);
        return tester(value);
    }

    private TesterMethodDelegate GetTesterMethodDelegate(Type type, object value)
    {
        TesterMethodDelegate tester;
        if(!this.cache.TryGetValue(type, out tester))
        {
            var thisType = typeof(OptimizedDefaultValueTester);
            var methodInfo = thisType.GetMethod("IsDefaultValue", BindingFlags.Static | BindingFlags.Public);
            methodInfo = methodInfo.MakeGenericMethod(type);
            tester = (TesterMethodDelegate) Delegate.CreateDelegate(typeof(TesterMethodDelegate), methodInfo);
            this.cache.Add(type, tester);
        }
        return tester;
    }

    public static bool IsDefaultValue<T>(object obj)
    {
            // cf. extraits de code précédents. 
    }
}

Les points remarquables :

• Ligne 1 : On utilise le type de délégué générique Func<T,TReturn> du Framework 3.5, derrière un alias (TesterMethodDelegate).
• Ligne 5 : Les instances de TesterMethodDelegate sont mises en cache grâce à un champ d’instance de type Dictionary<TKey,TValue> et sont indexées par type.
• Ligne 16 : A chaque appel à IsDefaultValue, on regarde si un TesterMethodDelegate a déjà été créé pour le type passé en paramètre. Si c’est le cas, on récupère l’instance dans le cache, sinon, on la crée avant de l’ajouter au cache.
• Ligne 10 : L’appel dynamique via la méthode Invoke a disparu, on invoque directement l’instance de TesterMethodDelegate récupérée.

Toujours selon le même test, les performances sont améliorées. On passe de 10625 ms pour 700000 appels, à 506 ms. C’est environ 20 fois mieux, hourra.

Peut-on aller plus loin ?

Pas vraiment, si on ne considère que les performances. Par contre, il est possible d’encapsuler le mécanisme d’optimisation précédent pour favoriser la réutilisabilité. Et pour cela, nous pouvons utiliser la memoization. Sans le savoir c’est un peu ce que nous avons imaginé jusqu’ici.

Cependant, il est possible en utilisant les méthodes anonymes (ou les expressions lambda en C# 3.0) de mettre en place une solution plus élégante, et autorisant la réutilisation du caching comme s’il s’agissait en quelque sorte d’un aspect. J’ai découvert cela en tombant sur ce post et j’ai été séduit.

Le principe consiste à créer une méthode capable de retourner une version mémoizée d’un délégué. On peut même en faire une méthode d’extension générique en C# 3.0:

public static class Memoization
{
    public static Func<T, TResult> Memoize<T, TResult>(this Func<T, TResult> function)
    {
        var cache = new Dictionary<T, TResult>();
        var nullCache = default(TResult);
        var isNullCacheSet = false;
        return  parameter => 
                {
                    TResult value;

                    if (parameter == null && isNullCacheSet)
                    {
                        return nullCache;
                    }

                    if (parameter == null)
                    {
                        nullCache = function(parameter);
                        isNullCacheSet = true;
                        return nullCache;
                    }

                    if (cache.TryGetValue(parameter, out value))
                    {
                        return value;
                    }

                    value = function(parameter);
                    cache.Add(parameter, value);
                    return value;
                };
    }
}

Décortiquons cette méthode :

• Elle prend en paramètre un délégué de type Func<T,TResult> et retourne un délégué du même type. Pour simplifier, on peut dire que la méthode d’extension prend en paramètre et retourne une fonction dont le prototype est le suivant : TResult Function(T param)
• La fonction retournée est construite via une expression lambda qui se charge d’encapsuler la logique de caching. Elle a pour rôle de mémoriser le résultat (de type TResult) de la fonction à chaque valeur différente de T pour laquelle on l’appelle.
• C’est la valeur sauvegardée qui est retournée lorsqu’elle est présente dans le cache. En effet, le résultat de la fonction pour un paramètre donné ayant déjà été déterminé, il ne sert à rien d’exécuter de nouveau la fonction avec le même paramètre.
• Dans cet exemple, l’expression lambda qui sert à créer la fonction retournée est une closure. C’est ici que réside toute l’ingéniosité de cette technique. Le dictionnaire est une variable locale à la méthode Memoize référencée par la méthode lambda, donc du point de vue de cette dernière l’état du cache sera conservé entre chaque appel.
• La méthode doit traiter un cas particulier : Si la valeur null est passée en argument de la fonction, il n’est plus possible d’utiliser un dictionnaire pour mettre en cache le résultat puisque les clés de ce dernier ne peuvent être nulles. Nous utilisons donc une variable spécialement dédiée : nullCache.

Bon, la memoization, c’est classe. Mais revenons à notre besoin. Quelle fonction a besoin d’être mémoizée ? Et bien tout simplement celle qui pour un type donné est capable de nous retourner le délégué pointant sur la bonne version fermée de IsDefaultValue<T>.

Une telle fonction peut avoir le prototype suivant :

Func<object, bool> GetTesterMethodDelegate(Type type);

Le type du délégué correspondant est le suivant :

Func<Type, Func<object, bool>>

En effet, il s’agit bien d’une fonction qui prend un type en argument, et qui retourne une autre fonction prenant un objet en argument et retournant un booléen.

Il nous reste plus qu’à examiner la nouvelle implémentation de IDefaultValueTester qui se base sur le principe :

using TesterMethodDelegate = Func<object, bool>;
using TesterMethodLocatorDelegate = Func<Type, Func<object, bool>>;

public class MemoizedDefaultValueTester : IDefaultValueTester
{
    private readonly TesterMethodLocatorDelegate testerLocator;

    public MemoizedDefaultValueTester()
    {
        // On crée une fonction capable de retourner la version fermée 
        // de la méthode IsDefaultValue<T> pour un type donné.
        this.testerLocator = type =>
                             {
                                 var thisType = typeof (OptimizedDefaultValueTester);
                                 var methodInfo = thisType.GetMethod("IsDefaultValue", BindingFlags.Static | BindingFlags.Public);
                                 methodInfo = methodInfo.MakeGenericMethod(type);
                                 var tester = (TesterMethodDelegate)Delegate.CreateDelegate(typeof(TesterMethodDelegate), methodInfo);
                                 return tester;
                             };

        // On mémomize cette fonction en appelant notre méthode d'extension
        this.testerLocator = this.testerLocator.Memoize();
    }

    public bool IsDefaultValue(Type type, object value)
    {
        var tester = this.testerLocator(type);
        return tester(value);
    }

    public static bool IsDefaultValue<T>(object obj)
    {
         // cf. extraits de code précédents. 
    }
}

Nous pouvons constater que :

• Un nouvel alias (TesterMethodLocatorDelegate) est introduit pour le type générique Func<Type,Func<object,bool>>
• La classe possède un champ d’instance (testerLocator) de type TesterMethodLocatorDelegate qui est initialisé dans le constructeur.
• La méthode d’extension Memoize définie plus tôt est utilisée pour mémoizer le TesterMethodLocatorDelegate, toujours au niveau du constructeur.
• L’implémentation de la méthode IsDefaultValue est extrêmement simplifiée. Via la version mémoizée du TesterMethodLocatorDelegate, on récupère un TesterMethodDelegate qui peut être invoqué directement afin d’effectuer le test sur la valeur passée en paramètre.

Les performances de cette solution sont les mêmes que celles mesurées pour la précédente : environ 510 ms. Mais à présent, nous disposons d’une méthode Memoize pouvant être réutilisée.

Hum. Attendez… Pourquoi ne pas la réutiliser alors, pour memoizer aussi les instances de TesterMethodDelegate retournées par le TesterMethodLocatorDelegate ? Il y aurait ainsi deux niveaux de mémoization, et peut-être à la clé un petit gain de performance supplémentaire.

La modification se limite donc à ajouter un nouvel appel à la méthode Memoize dans le constructeur du MemoizedDefaultValueTester :

public MemoizedDefaultValueTester()
{
    // On crée une fonction capable de retourner la version fermée 
    // de la méthode IsDefaultValue<T> pour un type donné.
    this.testerLocator = type =>
                         {
                             var thisType = typeof (OptimizedDefaultValueTester);
                             var methodInfo = thisType.GetMethod("IsDefaultValue", BindingFlags.Static | BindingFlags.Public);
                             methodInfo = methodInfo.MakeGenericMethod(type);
                             var tester = (TesterMethodDelegate)Delegate.CreateDelegate(typeof(TesterMethodDelegate), methodInfo);

                             // On retourne à présent une version mémoizée du TesterMethodDelegate :
                             return tester.Memoize();
                         };

    // On mémoize cette fonction en appelant notre méthode d'extension
    this.testerLocator = this.testerLocator.Memoize();
}

Le test des performances indique à présent que les 100000 itérations ont eu lieu en 320 ms ! Ce n’est pas aussi efficace que la première étape d’optimisation, mais proportionnellement cela conduit tout de même à une amélioration significative : environ 30%.

Attention quand même : Si notre premier usage de la memoization était justifié, le second peut être très dangereux. Nous gagnons des millisecondes, mais nous perdons des octets. Et dans le scénario actuel, il est même probable que la memoization des TesterMethodDelegate conduise à une OutOfMemoryException rapidement…

Conclusion

Nous nous sommes contentés d’évoquer la solution d’optimisation impliquant la génération de code IL. Dans le contexte de la problématique discutée, elle n’offrait aucun avantage par rapport à celle que nous avons exposée. Pire, elle imposait une étape inutile. Toutefois, certains besoins plus complexes dépassent le cadre des invocations dynamiques de méthodes et peuvent tout de même être adressés efficacement en recourant à la génération de bytecode. Je pense que cela sera le sujet d’un prochain article.

Quant à la technique détaillée dans celui-ci, elle est simple et permet d’obtenir des performances acceptables dans la majorité des scénarios pour lesquels l’utilisation de la réflexion est nécessaire.

Cela fait presque deux raisons de ne plus avoir systématiquement peur de la réflexion. Par contre, si vous n’en avez pas peur du tout, il serait peut-être temps de s’y mettre doucement…