Etude exploratoire de Linq - CoDE - de l'Université libre de Bruxelles

4.2.5 Performances
Les questions de performance sont toujours à garder à l’œil lorsque mapping il y a. En effet, le
mapping n’est jamais qu’une ou plusieurs couches insérées dans une pile parfois déjà conséquente.
La performance n’est pas toujours facile à cerner, en revanche. Nous pouvons d’ores et déjà parler
de performances exprimées en temps développeurs car nous avons vu ce qu’il en était de la syntaxe
et de la simplicité de mise en œuvre. Le travail est plus rapide et moins porteur d’erreurs ([1] utilise
les termes de « less error prone » pour désigner le développement avec Linq to Sql). Si le temps de
mise en œuvre est réduit par rapport à une approche ADO.NET qu’en est-il de la qualité ? Les codes
auto-générés sont souvent pointés du doigt dans ce domaine. Et les temps de réponses, seront-ils
satisfaisant ? Nous allons réaliser plusieurs tests afin de nous forger notre propre opinion.
4.2.5.1 Test d’insertions
Nous allons ici envisager un scénario très simple, à savoir une succession d’insertions dans une table
relationnelle vierge. Nous mettrons en compétition une version Linq to Sql avec une version
ADO.NET. Les requêtes seront groupées ainsi que le ferait une application avec base de données
locale, dans un but de réduction du nombre d’accès disques. La situation est exprimée ci-dessous en
pseudo code :
DateTime star t = now ; //start pour le test 1
for(int i=1 ; i < nbrOps ; ++i)
{
requete.ajout(insertion unitaire);
}
requete.Execute() ;
DateTime end = now ; //Ecart = end – start
Les codes utilisés lors de ce test sont disponibles en annexe (Annexe 2 : codes de tests de
performances pour Linq to Sql). Après plusieurs exécutions de la version Linq pour un même nombre
d’opérations, un phénomène curieux apparaît. Cette version est plus lente à la première exécution
du test, et les temps de réponses se stabilisent dès la deuxième exécution du test. C’est assez
inattendu et rien, à ce stade de notre étude, ne semble pouvoir justifier cela. [1] nous apprend que le
DataContext rassemble toutes les informations nécessaires au mapping lors de sa première
utilisation. Le mapping est gardé en mémoire jusqu’à son remplacement par un autre mapping ou
jusqu’à la fermeture de Visual Studio. Le gain de temps observé varie entre quelques dixièmes à deux
secondes, quel que soit le nombre d’opérations demandées par la suite. Pour revenir à notre test,
nous pouvons désormais comparer la version ADO.NET aux deux temps de réponse de la version
Linq. De manière surprenante, la version Linq a été observée comme étant plus rapide pour ses deux
temps de réponse. Ceci semble aller contre toute la logique du mapping et en réalité, c’est là qu’un
examen plus approfondi du code permettra de dénicher l’astuce. Pour ce premier test, la version
ADO.NET a été construite de manière très naïve. La requête étant représenté par un string, celui-ci
est modifié à chaque tour de boucle pour représenter une requête de plus en plus longue. La
manipulation de ce string en mémoire va entraîner un nombre d’opérations responsables de
l’accumulation de ce retard. Notons déjà ici une des forces de Linq to Sql qui est de réaliser
l’optimisation pour le programmeur alors que la version ADO.NET peut fonctionner en étant très mal
programmée. En ne considérant que les temps d’accès à la base de données, la version ADO.NET
s’est montrée plus rapide, ce qui était beaucoup plus prévisible. Le temps d’exécution nécessaire
varie presque du simple au double entre les deux approches dans ces conditions. Ces temps varient
linéairement avec le nombre d’opérations à effectuer. L’ergonomie et la productivité du développeur