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

4.2.5.2 Test en situation concurrentielle
Le test suivant porte sur un contexte où les connexions sont nombreuses et indépendantes. Pour
simuler cette situation, nous allons simplement imposer au programme de ne considérer que des
insertions simples directement transmises à la base de données. Comme précédemment, un grand
nombre d’insertions seront effectuées mais cette fois elles seront transmises directement à la base
de données sans regroupement. Bien qu’il ne s’agisse pas d’un scénario vraiment réaliste, cela suffira
pour se faire une idée des performances relatives de Linq et d’une connexion plus traditionnelle.
Le graphique qui suit ce paragraphe montre les temps nécessaires (exprimés en millisecondes) à
l’envoi de toutes les requêtes une à une pour les deux méthodes, le nombre de requêtes de chaque
lot étant repris en ordonnée. On voit clairement que la courbe intitulée « Linq sequence» croît
exponentiellement avec l’augmentation du nombre de requêtes à satisfaire. L’explication principale
en est que Linq doit manipuler des objets en mémoire comme nous l’avons vu dans la section
« Opérations fondamentales » de ce chapitre, dernier paragraphe. Chaque ajout créé un objet
supplémentaire et cette modification a lieu en mémoire centrale, ce qui sera fait beaucoup plus
rapidement que l’envoi de la requête à la base de données. Chaque soumission entraîne l’analyse du
marquage de chaque objet, ce qui ralentit l’ensemble du programme. La méthode ADO.NET,
représentée par la courbe « ADO sequence », ne manipule pas d’autres objets que les strings utilisés
pour construire les requêtes, celles-ci étant ensuite transmises au gestionnaire de la base de
données. Les temps d’accès varient donc selon une progression linéaire. La troisième courbe
présente sur le graphe représente les temps d’accès correspondant pour une utilisation idéalisée de
Linq. Utilisation idéalisée car l’envoi des requêtes n’est fait qu’au dernier moment, économisant ainsi
sur les temps d’analyse de marquages par la sentinelle. L’appel à la fonction SubmitChanges réalise
l’appel à la base de données et toutes les entités marquées comme étant « à insérer » vont générer
une requête Sql correspondant à leur insertion. En n’effectuant cette tâche qu’une seule fois, on
aperçoit que le gain de temps est conséquent 10 . Dans la réalité pratique, on pourrait regrouper
plusieurs requêtes par petits lots afin d’économiser un peu sur les accès successifs à la base de
données. Mais un appel unique est impensable, du fait que « la fin » est impossible à prévoir en
pratique ainsi qu’à cause des problèmes d’accès concurrentiels aux données. Les possibilités
d’optimiser Linq relèvent principalement de la gestion des conflits, de la synchronisation et du design
de l’application. Les performances en situation réelles sont certainement moins bonnes que le cas
idéal mais vraisemblablement plus proches de cette valeur que de celle de la version naïve.
10 Cette observation semble n’apparaître nulle part, *4+ le laisse tout juste sous-entendre.