03 novembre 2011
publié par 
L'analyseur de performances permet de voir le temps nécessaire à l'exécution de tous les traitements d'une application. En phase d'optimisation, il est donc capital de l'utiliser afin de repérer les traitements les plus coûteux en temps. Il devient ainsi très simple de cibler les améliorations possibles.

Dans le rapport de performances, on peut avoir un temps consacré au "traitement interne du moteur d'exécution". Il s'agit d'un regroupement de traitements automatiques. Il est prévu de faire évoluer l'analyseur de performances afin d'avoir le détail de tous ces traitements regroupés, et ainsi mieux détailler l'analyse. En attendant, voici les principales actions comptabilisées dans ce "traitement interne du moteur d'exécution" :

  • chargement des images utilisées par l'élément (fenêtre, état...),
  • initialisation des champs à remplissage automatique : table fichier, liste/combo fichier, colonne de table combo,
  • parcours de données à l'aide d'un POUR TOUT,
  • temps de récupération et de mémorisation de paramètres des fenêtres,
  • exécutions implicites HFSQL/Autres bases : ouverture automatique de connexions, de fichiers de données,
  • temps d'exécution des appels aux services Web, requêtes http, serveur ftp.

A partir de cette liste, il est donc possible d'agir si pour un élément particulier le "traitement interne du moteur d'exécution" prend un temps plus important qu'à l'accoutumée :
  • utiliser l'audit dynamique afin de repérer une éventuelle image référencée à un emplacement erroné. Il s'agit du cas le plus courant, la recherche d'un fichier inexistant pouvant être conteuse en temps suivant la configuration,
  • pour les table fichier, liste/combo fichier, colonne de table combo, tester dans un traitement isolé le temps d'exécution des requêtes qui leurs sont associées (par exemple exécution de "HExecuteRequete" + "HNbEnr" de la requête),
  • chronométrer séparément un POUR TOUT afin de voir si un parcours peut être remplacé par une requête,
  • pour la mémorisation de paramètres des fenêtres, rechercher InitParamètre (une mémorisation dans un fichier plutôt que la base de registre est plus longue), et essayer de réinitialiser les paramètres...
En dernier recours il est toujours possible de surveiller l'ensemble des entrées/sorties d'une application. Cela permet de cerner toujours plus finement ce qui est fait, et donc à un instant donné de déterminer ce qui coûte du temps.

Il faut souligner que l'analyseur de performances a un rendu nettement amélioré à partir de la version 17 de WINDEV.

N'hésitez pas à me solliciter via le menu "? ... Requête au Support Technique" de WINDEV pour toute interrogation, ou suggestion d'amélioration au sujet de l'analyseur de performances.

< Retour