CIL is stack-based, in difference to many native machine languages that are register-based. This means that everytime you want to manipulate an object (a type or an unit of code) you put it on the stack and call an op code (language instruction) that is performing an operation, i.g. adding two values. Thereby adding the two objects (Int32 or simply 32-bit integers) on the top of the stack and leaving the sum of those. The stack should be empty at the end of runtime. See the example.

IL:

ldc.i4.3 //Loads a constant in the stack
ldc.i4.2
add

Stack:

2 //Int32
3 //Int32

After the last operation (add) this will remain on the stack:

5 //Int32

If you had only one object on the stack and performed the add operation you would get a stack underflow.
The opposite is stack overflow that is caused by objects remaining on the stack in the end of the program. These errors are often caused by bugged compilers.

Some common op codes are:

ldstr "Kazoom" //Puts a string on the stack
ldarg.0 //Loads the method argument at the index 0 and puts it on the stack
ldc.i4.29 //Puts an integer, 29, on the stack
ldloca.s lcal //Loads a local (name lcal) an places it on top of the stack
call //Used when calling a method
newobj //Used when instanciating an object

// Arithmic operations that pops two values from the top of the stack.
add
sub
mul
div
mod

This is the most simple part of the CIL language. Because of the object-oriented nature of CLI you are able to use some OOP approach in your programming. Many of the constructs found in the programming languages at a higher level are represented directly as IL. For instance, a class declaration looks like this:

.class public MyClass
{

}

A class can be declared as static (non-instance class) with the static attribute static.

.class public static MyStaticClass
{

}

Classes contains methods defined this way:

.method Int32 Add(Int32, Int32)
{
      //Load both arguments on the stack and add them, then return the value.
      ldarg.0
      ldarg.1
      add
      ret
}

Likewise to classes, methods can also be marked as static.

This syntax, is like the class syntax, very similar to the C style. The only difference is the IL opcodes instead of ordinary statements. Another thing you must know is that methods always ends with a return statement even though they do not seem to return any value. In reallity theres a value, void. This will the runtime engine (virtual machine) handle for you.

To make a method the entrypoint of the program you add the .entrypoint attribute inside the method body. Notice that you can only have one entrypoint in a program.

Local variables (mostly refered to as locals) are also defined as attributes inside a method.

.locals init (
      [0] string str1
      [1] Int32 int1)

Those locals named by the compilers often have a random name consisting of letters and a number.

Because of performance there is also a .maxstack attribute which sets the maximum numbers of items on the stack. This tells the runtime engine that this method needs a stack of this size. Now is the virtual machine able to manage the amount of memory.

There are a lot of other things as well. I will not dig deeper into it because it is to much at a time. If you are familiar with a high-level language or any other stack-based and object-oriented intermediate language, like the Parrot Intermediate Language you, should understand the IL too.

Finally, this is the Hello World program in IL style. You can try to assemble it with ILASM (IL Assembler) ported with .NET Framework or Mono.

.method public static void Main() cil managed
{    
      .entrypoint    
      .maxstack 8    
      ldstr "Hello world!."    
      call void [mscorlib]System.Console::WriteLine(string)    
      ret
}

Je me suis appliqué, un parfait cover to cover, mais je le regrette un peu. Il ne doit pas être évident d'écrire un livre sur un sujet aussi chiant particulier, donc je ne peux raisonnablement pas être aussi acerbe que déçu. Car j'ai été assez déçu.

Si on ne s'attend pas à mourir de rire à chaque page lorsqu'on entame la lecture d'un livre du genre (avez-vous déjà essayé de faire une blague sur le CIL ?), on espère au moins en tirer quelque chose, ou plus exactement, quelque chose que l'on n'aurait pas pu - ou pas mieux pu - apprendre ailleurs. CIL Programming m'a donné l'impression d'être trop souvent approximatif à plusieurs niveaux : structure, rédaction, exemples, blagues (oui, Jason a essayé), références, etc. Pour être honnête, j'ai abordé cette lecture avec pour objectif d'acquérir une meilleure compréhension du langage intermédiaire de la plateforme .NET et plus particulièrement des possibilités offertes aux langages de plus haut niveau quant à sa génération/manipulation ; mais j'avais déjà une compréhension globale du langage ainsi qu'une expérience assez modeste de l'API System.Reflection.Emit.

C'est peut-être pour cette raison que j'ai été déçu. Quoi qu'il en soit, il serait dommage qu'en ayant une connaissance superficielle du sujet on en sache déjà trop pour trouver la lecture profitable. On parle bien d'un livre, hein, pas d'un article de blog ou d'un post dans le forum de codes-sources.com.

Le livre progresse doucement, trop doucement ; il frôle parfois le formalisme soporifique d'une spécification de langage sans pour autant parvenir au même niveau de complétude et de concision. Beaucoup de questions sont laissées en suspens malgré l'abus de références croisées (assez fatigantes), et cela conduit inévitablement le lecteur à se demander s'il n'a pas été trompé lorsqu'il arrive aux annexes.

Outre les chapitres qui listent les différents codes d'opérations du langage, vous pourriez éventuellement trouver un intérêt à lire en diagonale au moins les chapitres 5, 6 et 7 (cf. liste ci-dessous). Le chapitre 8, qui aurait pu être le plus intéressant pour les développeurs voulant générer dynamiquement du CIL est finalement compromis par la qualité de l'exemple lui-même (pourtant pertinent).

Pour le contenu, voici la liste des chapitres :

• Chapter 1: Language Interoperability
• Chapter 2: ILASM Directives and Attributes
• Chapter 3: CIL Opcodes
• Chapter 4: ILASM and CIL in Practice
• Chapter 5: Debugging CIL
• Chapter 6: .NET Languages and CIL
• Chapter 7: Emitting Types
• Chapter 8: Dynamic Proxies in .NET
• Chapter 9: CIL Tips
• Appendix A The Future of CIL
• Appendix B .NET

Au risque donc de paraitre déraisonnable, je vous déconseille assez franchement ce livre.

Please check out my compiler (Pascal Compiler for .NET Framework v.0.0.1).
Requires Windows XP/Vista and .NET Framework 3.5.

Download it here!

Notes:

The compiler...

• supports definitions of types, functions, procedure and variables.
• supports Primitive types such as Integer, Double, Boolean, Char and String.
• has these Complex types: Record, Enum and Dynamic Array.
• can only parse the expression WriteLn([stringliteral]);
• only supports single sourcefiles.

First I just want to explain some words that I will or may use in this series of articles.

• assembly language - machine specific language dependend of the instruction set of the system.
• programming language - a language constructed to make software development easier by introducing certain abstractions that makes it easier for humans to write and understand.
• compiler - a program that compiles (translates) codes written in a high level-language into object code (assembly language). A compiler for a assembly language is usualy called assembler.
• IL (a.k.a CIL and MSIL) is a high-level assembly language created by Microsoft that is to be executed on a virtual machine made according the Common Language Infrastructure standard. Can be executed by virtual machines such as the CLR (Windows) or the Mono Runtime (Linux). This means that IL is not bound to a specific platform, in contrast to native assembly languages. IL is Microsoft's response to Sun's Java Bytecode.
• virtual machine - A program working on top of a system that simulates another system. In this case the CLR or the Java Runtime that is converting bytecode into native code (object code) and executes it. A virtual machine can therefore test the code and then execute it if it does not contain any errors or bad code.
• front-end and back-end are terms used in compiler construction. Front-end usaully refers to the scanner and parser. That is why scanner and parser sometimes is incorrectly known as the parser. The Back-end contains the code generator and preprocessor (if any). The idea of these two is that you can switch parts, for example writing a new code generator for another system, without changeing the rest (the front-end).
• lexical scanner, lexer or scanner is a program that creates tokens of the input code by following a set of rules. A scanner is usually constructed to work as a Defininite State Machine and use regualar expressions. We have for example the following line of code (written in C-style): int myNumber = 20 + 3; "int" would be a keyword, "myNumber" a identifier, "=" an operator, "20" a number or integral and so on. Scanners are often generated by a scanner generator because they are performing better than those written by programmers. 
• parser - A program that is considered the heart of the compiler because it is creating a presentation of the code that is easier to use when generating machine code. The parser is following rules that decides how the code is going to be interpreted and then creates an Abstract Syntax Tree (AST).
  The AST is then easily converted to machine code by the code generator.

I am using an object-oriented approach when constructing my compiler. That means that there will be objects that will symbolize for example tokens, the scanner, the parser and the code generator. Why? Because it is a lot easier to think that way. I cannot manage to do this the procedural way like legendary constructors like Niklaus Wirth did. Another reason is that I am a OOP programmer and I'm attached to C# and the .NET Framework.

The purpose of this project is only educational. I want to learn how a compiler works and especially the parts of it. I am not trying to build a "perfect" compiler that supports all the CLR features. I will not concentrate on the performance either because that is not important. I want the compiler to work before I think of that, and of course it is of beyond the scope of this project.

I want the back-end and front-end to be separate and independent in that way that you can reuse its components and modify them if necessary. But I will firstly concentrate on getting everything working and then try to make these changes.

I have defined a small OO language called Simple Programming Language that I will use as the source language compiled by the compiler that I will write. More details on it in one of the following blogposts.

I have decided to implement Pascal instead of my own SPL. It's because I have had som issues with it. It is not a good thing to start implementing a compiler for a full OOP langauge as ones first real project.

Anyway, stay tuned!

Some interesting ways Twitter can and is being used:

Businesses can use Twitter tools to help them.

For customer service support

Marketing related uses for Twitter

Way to report the news (forget email Breaking News updates)

Water your plants via Twitter

Share your photos

Share your blog posts

Get a weather forcast

Keep track of your diet

Reminder to step back and reflect

Remember the milk (manage your tasks)

See where all the tweets come from (maps)

Propose to someone

I even use it as a safety feature. When I'm out walking the dogs in remote areas, I make sure I Twitter what I'm doing and where from my Facebook app on my Blackberry. Who knew that Twitter was this and much, much more...

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 :

[code language='csharp']
public interface ICloner
{
object Clone(object toClone);
}
[/code]

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 :

[code language='csharp']
[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);
}
[/code]

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

[code language='csharp']
public class Cloner : ICloner
{
private readonly Func> clonerLocator;

public Cloner()
{
this.clonerLocator = ((Func>)GetCloner).Memoize();
}

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

private Func 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;
}
}
}
[/code]

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 :

[code language='csharp']
public class CilCloner : ICloner
{
private readonly Func> clonerLocator;

public Cloner()
{
this.clonerLocator = ((Func>) GetCloner).Memoize();
}

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

private Func 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) dynamicMethod.CreateDelegate(typeof (Func));
}
}
[/code]

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 :

[code language='csharp']
public void CallMethod(object target, string methodName)
{
Type type = target.GetType();
MethodInfo methodInfo = type.GetMethod(methodName);
if (methodInfo != null)
{
methodInfo.Invoke(target, null);
}
}
[/code]

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 :

[code language='csharp']
[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()));
}
[/code]

L'interface IDefaultValueTester est simple :

[code language='csharp']
public interface IDefaultValueTester
{
bool IsDefaultValue(Type type, object value);
}
[/code]

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 :
[code language='csharp']
public static bool IsDefaultValue(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));
}
[/code]

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 :

[code language='csharp']
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(object value)
{
// cf. extrait de code précédent.
}
}
[/code]

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 :

[code language='csharp']
[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));
}
[/code]

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 :
[code language='csharp']
using TesterMethodDelegate = Func;

public class OptimizedDefaultValueTester : IDefaultValueTester
{
private readonly Dictionary cache = new Dictionary();

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(object obj)
{
// cf. extraits de code précédents.
}
}
[/code]

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:

[code language='csharp']
public static class Memoization
{
public static Func Memoize(this Func function)
{
var cache = new Dictionary();
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;
};
}
}
[/code]

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 :

[code language='csharp']
Func GetTesterMethodDelegate(Type type);
[/code]

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

[code language='csharp']
Func>
[/code]

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 :

[code language='csharp']
using TesterMethodDelegate = Func;
using TesterMethodLocatorDelegate = Func>;

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 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(object obj)
{
// cf. extraits de code précédents.
}
}
[/code]

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 :

[code language='csharp']
public MemoizedDefaultValueTester()
{
// On crée une fonction capable de retourner la version fermée
// de la méthode IsDefaultValue 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();
}
[/code]

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...