Pendant mes heures de travail, j’ai réalisé une petite expérience que je souhaiterais approfondir par la suite mais cela dépendra évidemment du temps que je pourrais y accorder. En effet, celle-ci consiste tout simplement à tester les performances à la fois des fonctions natives à WinDev pour manipuler les bases de données telles que HyperFileSQL, ainsi que de la fonction qui permet d’exécuter une requête codée en SQL. J’avais déjà testé très rapidement le cas d’une mise à jour d’un seul enregistrement et bien sûr j’ai eu la brillante idée que de recommencer mais en gardant 10 valeurs, tout en tenant compte du trafic réseau éventuel.

Les conditions de test sont les suivantes :

• Application WinDev tournant sur un laptop HP ProBook 4720S avec 4 GB de RAM, connecté en filaire à 100 Mbps.
• Connexion native à une machine IBM AS/400 (DB/2), elle aussi connectée en filaire.
• Tranche horaire du test : 12h45 à 13h15, heures où normalement le réseau n’est pas trop surchargé.

Les deux cas testés sont :

• Les fonctions « HModifie » (qui effectue une mise à jour dans une table) accompagnée de « HDésactiveFiltre » (qui désactive les filtres précédemment placés sur la table), « HTrouve » (qui renvoie un booléen si le record est trouvé) et « HLitPremier » (qui lit le premier résultat).Elles forment l’ensemble « HModifie« . L’une des fonctions a un temps d’exécution de l’ordre de quelques microsecondes, sa valeur n’a donc pas été additionnée au total du temps pour ce cas. Attention toutefois, la fonction ne peut pas agir sur plusieurs enregistrements, donc à partir du moment où il faut boucler, la requête SQL pourrait prendre rapidement le dessus !

• La fonction « HExecuteRequeteSQL » (qui lance une requête texte) accompagnée de « HAnnuleDéclaration » (qui libère les ressources allouées). Elles forment à elles deux l’ensemble « HExecuteRequeteSQL« . Le critère de recherche choisi peut avoir impacté les performances.

Voici un graphique reprenant les dix valeurs retenues. Celles-ci ont été prises les unes à la suite des autres, durant la tranche horaire indiquée plus haut dans cet article. Les temps d’exécution sont exprimés en millisecondes et l’axe horizontal correspond au nombre d’appels effectués. Plus la valeur est petite, mieux c’est :

Selon les conditions de test, il semblerait que le fait d’exécuter directement une requête SQL de mise à jour plutôt que d’utiliser la fonction native de modification ralentisse l’exécution. Attention bien sûr, cela peut dépendre de l’index choisi dans la condition « where » de votre requête SQL! Dans chacun des cas testés, c’est ce que l’analyseur de performances WinDev nous a indiqué. Voici ce que donne la moyenne de toutes les valeurs réunies, pour chacun des deux cas :

L’utilisation de « HModifie » semblerait être bien plus rapide que le deuxième cas. Cela n’indique cependant pas à quelle échelle le ralentissement se produit (en cas de plusieurs enregistrements requérant une mise à jour, la fonction doit être répétée dans une boucle car celle-ci ne peut agir que sur une seule ligne à la fois, contrairement à une requête SQL. Il serait donc intéressant de tester les performances lorsqu’il s’agit de modifier plus d’un enregistrement à la fois !)

En conclusion, attention au choix de l’index pour réaliser votre requête SQL! Celle-ci peut amener à une mise à jour plus lente. Cependant, on conseille plus souvent d’utiliser ce type de requête malgré le fait que les fonctions natives soient optimisées pour ce genre de traitement.