Comment rendre vos applications ILE plus performantes

Beaucoup de programmeurs System i ignorent les nombreux moyens d’optimisation du code ILE. Pour vous aider dans votre choix, je passe en revue les options offertes : des outils les plus simples à disposition de tous les programmeurs, jusqu’aux options plus complexes visant des pratiques de coding spécifiques.

Qu’est-ce que l’optimisation ? Il existe de nombreux moyens d’améliorer la performance du code, comme d’utiliser les algorithmes les plus efficaces pour votre tâche. Mais vous pouvez aussi accélérer vos applications au stade de la création, simplement en choisissant les bonnes options. Ces dernières ordonnent au système d’analyser plus profondément le code pour produire une meilleure combinaison d’instructions matérielles. Les programmes ainsi optimisés tournent plus rapidement, généralement sans avoir à modifier le code source.

Le principal intérêt des techniques décrites ci-après est de ne pas vous coûter un sou. Elles sont toutes incluses dans le support du système d’exploitation de base, conjointement aux compilateurs  ILE présents sur votre système. Cependant, aucune de ces optimisations n’est activée par défaut : c’est vous qui les sélectionnerez sur la ligne de commandes au moment de la compilation du code.

Niveau d’optimisation dans ILE

Chaque commande du compilateur ILE a un paramètre OPTIMIZE qui vous permet de choisir l’un des quatre niveaux d’optimisation (comme on le voit dans le tableau ci-dessous). Tous les compilateurs acceptent des valeurs numériques pour le niveau d’optimisation, et certains acceptent aussi les valeurs nommées *NONE, *BASIC, et *FULL (équivalentes aux niveaux 10, 20, et 30, respectivement). Il n’y a pas d’équivalent nommé pour le niveau d’optimisation 40.

Les différents niveaux d’optimisation.

La compilation se déroule en plusieurs étapes. En premier lieu, le compilateur de votre langage source convertit le code en une représentation intermédiaire dite Machine Interface (MI). Cette représentation de votre module, jointe au niveau d’optimisation choisi, est transmise à un composant spécial du système d’exploitation : le traducteur optimisant (optimizing translator). Celui-ci est chargé de convertir la représentation MI de votre module en instructions matérielles. Le niveau d’optimisation indique le degré d’effort du traducteur pour rendre ces instructions efficaces.

La figure 1 montre comment le niveau d’optimisation choisi affecte votre code à divers égards. L’effet le plus évident est le degré d’analyse appliqué au code, et, par voie de conséquence, la durée de la compilation. Avec le niveau d’optimisation 10 (*NONE, la sélection par défaut), il y a très peu d’optimisation pour obtenir la compilation la plus rapide possible. Au niveau d’optimisation 20 (*BASIC), le traducteur optimisant examine chaque section du code (ligne droite sans branchement) dans votre module indépendamment, et rend chaque section la plus rapide possible. Dans ce cas, la compilation dure un peu plus longtemps qu’avec le niveau d’optimisation 10.

Les niveaux d’optimisation 30 (*FULL) et 40 sont bien plus exigeants. Le traducteur analyse tout le code dans chaque procédure dans l’intention d’accélérer celle-ci au maximum. L’application est nettement plus rapide mais la compilation est un peu plus longue. Entre les niveaux 30 et 40, le temps de compilation ne présente pas de différence notable.

Le niveau d’optimisation 40 fait la même chose que le niveau 30 mais essaie aussi d’accélérer les appels de procédure. Sur les versions du système d’exploitation antérieures à 6.1, le niveau d’optimisation 40 perturbe deux choses : la collecte des traces de jobs et l’utilisation de Performance Explorer. Si cela vous concerne, choisissez plutôt le niveau 30 sur de tels systèmes. À partir de la version 6.1, le niveau 40 ne présente plus cet inconvénient.

Sachez aussi que de hauts niveaux d’optimisation gênent l’utilisation du System Debugger. Au niveau 20, si vous examinez la valeur d’une variable, vous verrez toujours sa valeur courante. Mais si vous modifiez la valeur d’une variable, celle-ci risque de ne pas prendre effet immédiatement. Il se peut qu’elle soit transférée temporairement de son lieu de stockage à un registre matériel plus rapide ignoré du débogueur.

Aux niveaux 30 et 40, on ne peut pas compter sur le seul débogueur pour inspecter les variables. La valeur présente dans l’emplacement de stockage de la variable peut être différente de celle qui sert au calcul en un point quelconque de l’exécution. A ces niveaux d’optimisation, vous pouvez encore avancer pas à pas dans le code et utiliser des points de rupture. Mais sachez que la lecture et la modification des valeurs de stockage n’est plus prévisible.