Optimiser votre application, PARTIE 2

Si vous en êtes encore à modifier fréquemment le code, le temps de compilation a priorité sur le degré d’optimisation. Donc, à ce stade, vous devriez choisir le niveau 10 ou 20. Je recommande d’utiliser le niveau 20 le plus souvent, et de ne descendre au niveau 10 que si vous envisagez d’employer le débogueur.

Dès que votre code est stable et proche de l’utilisation en production, vous devriez passer au niveau d’optimisation 30 ou 40. À partir de la release 6.1, le niveau 40 est préconisé pour tous à ce stade. Si vous utilisez encore une version antérieure, choisissez entre 30 et 40, selon que la trace de jobs et Performance Explorer sont importants pour le reste du développement.

À noter que, pour changer le niveau d’optimisation, il n’est pas nécessaire de recompiler le code à partir des fichiers source. CHGPGM et CHGSRVPGM sont à votre disposition pour recréer votre code applicatif avec un niveau d’optimisation différent.

Les programmeurs qui ne sont pas habitués à de hauts niveaux d’optimisation passent facilement au niveau 30 … pour constater que leurs programmes ne fonctionnent plus. Ces mêmes programmeurs sont souvent tentés de blâmer le compilateur avant de revenir au niveau 10 ou 20. Ne tombez pas dans ce piège ! Bien qu’aucun code ne soit parfait, il est peu probable que le compilateur ou le traducteur soit coupable.

Certaines erreurs de programmation courantes passent souvent inaperçues à de bas niveaux d’optimisation, mais font encore des dégâts quand l’optimisation est activée. La cause la plus fréquente de ce problème est une variable qui a été utilisée dans un calcul avant de recevoir une valeur. A ce bas niveau d’optimisation, cette variable reçoit souvent une valeur par défaut accidentelle  (telle que zéro) qui n’expose pas l’erreur. À des niveaux plus élevés, la variable a plus de chances de contenir une mauvaise valeur moins prévisible, ce qui facilitera la détection de l’anomalie.

Si vous commettez l’erreur d’abaisser le niveau d’optimisation du code, vous courez le risque de dissimuler dans votre code un bogue que vos clients découvriront avant vous. Il est bien préférable à long terme de détecter pourquoi le programme ne fonctionne pas correctement à un niveau d’optimisation supérieur.

Caractéristiques applicatives

Avant de passer à des techniques d’optimisation plus pointues, il est bon de définir vos attentes concernant l’application. Parfois, l’optimisation d’un programme ne semble pas affecter beaucoup sa performance. Quelle en est la raison ?

Il faut bien voir que toutes les applications sont différentes. Plusieurs caractéristiques importantes qui affectent l’optimisation sont révélées par les questions suivantes sur l’application :

•    Comment est-elle structurée ?
•    Que fait-elle ?
•    Où passe-t-elle son temps ?

Par “structurée,” j’entends comment vous divisez l’application : est-ce une procédure unique et monolithique ? Est-elle fragmentée en de nombreux modules, chacun contenant de nombreuses procédures ? Les programmes de service sont-ils très utilisés ? Les réponses à ces questions détermineront l’efficacité des différentes optimisations.

Le travail qu’une application effectue est étroitement lié à l’endroit, dans le processus global, où elle passe son temps. Par exemple, des applications qui lisent une suite d’enregistrements de base de données pour produire un rapport récapitulatif, sont susceptibles de fonctionner la plus grande partie de leur temps dans le système d’exploitation, où elles effectuent des opérations d’I/O vers la base de données et le fichier spool. Les applications qui exécutent de longues et fréquentes requêtes sur la base de données sont aussi vouées à passer beaucoup de temps dans le système d’exploitation plutôt que dans le code applicatif. À l’inverse, des applications qui analysent des données à l’aide d’une logique longue et complexe, bénéficieront davantage de l’optimisation parce que la plus grande partie de leur temps de traitement sera consacrée à exécuter le code applicatif.