Lorsqu'on cherche à optimiser des traitements SAS© ou à surveiller la performance d'une chaîne de production, l'information par défaut fournie dans la fenêtre "Log" peut s'avérer frustrante.
Par défaut, SAS© affiche les statistiques de performance (temps réel, temps CPU, mémoire) après chaque étape (DATA step ou PROC).
| 1 | NOTE: DATA statement used (Total process time): |
| 2 | real time 0.01 seconds |
| 3 | user cpu time 0.00 seconds |
| 4 | system cpu time 0.01 seconds |
La question récurrente est : Comment obtenir le cumul de ces statistiques pour l'ensemble d'un programme contenant des dizaines d'étapes consécutives ?
Voici les trois méthodes principales, de la plus simple à la plus avancée.
C'est la solution la plus immédiate si vous n'avez pas besoin d'interactivité. Lorsque vous exécutez un programme SAS© en mode Batch (via la ligne de commande ou un ordonnanceur), SAS© change légèrement son comportement de journalisation.
À la toute fin du fichier .log généré, SAS© insère automatiquement un résumé statistique de toute la session.
Comment faire : Au lieu d'ouvrir SAS© Enterprise Guide ou SAS© Base en interactif :
Lancez votre programme via l'exécutable système (ex: sas©.exe -sysin mon_programme.sas©).
Ouvrez le fichier log résultant (mon_programme.log).
Allez tout en bas du fichier pour trouver le bloc "SAS© Session Statistics".
Si vous devez historiser ces performances (par exemple, pour comparer la vitesse d'exécution d'un traitement jour après jour), la lecture manuelle du log ne suffit pas. La solution recommandée par les experts est de créer un petit programme qui "lit" vos logs.
L'idée est d'utiliser SAS© pour lire ses propres fichiers de sortie texte.
Le concept :
Activez l'option FULLSTIMER au début de votre programme principal pour avoir le maximum de détails.
Une fois le programme terminé, lancez un script de "scraping" qui lit le fichier .log.
Cherchez les lignes commençant par "real time" ou "cpu time".
Extrayez les valeurs numériques et faites-en la somme.
C'est la méthode idéale pour construire des tableaux de bord de performance (Performance Monitoring).
Pour des besoins plus complexes (par exemple, mesurer le temps d'une section spécifique du code sans inclure l'initialisation),nous suggèrons d'utiliser ARM (Application Response Measurement).
ARM est un standard de l'industrie pour la mesure de performance, intégré dans SAS© via des macros spécifiques. Cela permet de définir des transactions "début" et "fin" personnalisées.
Exemple conceptuel :
| 1 | /* Initialisation du système ARM */ |
| 2 | %let _armagent=1; |
| 3 | %arm_init(appname="MonApplicationCritique"); |
| 4 | |
| 5 | /* Début du chronomètre pour une section précise */ |
| 6 | %arm_start(name="Etape_Importation"); |
| 7 | |
| 8 | /* ... Votre code lourd ici ... */ |
| 9 | DATA work.test; SET SOURCE.big_data; RUN; |
| 10 | |
| 11 | /* Fin du chronomètre et enregistrement du log */ |
| 12 | %arm_stop(name="Etape_Importation"); |
| 13 | |
| 14 | %arm_end(); |
Les résultats sont alors stockés proprement dans un fichier de log dédié ou une table, facilitant l'analyse précise sans avoir à parser du texte brut.
Si vous n'avez pas besoin de la précision CPU/Mémoire mais juste de la durée réelle ("Wall clock time") pour un bloc de code, vous pouvez simplement utiliser des variables macro au début et à la fin de votre script :
| 1 | /* Début du chronomètre */ |
| 2 | %let start_time = %sysfunc(datetime()); |
| 3 | |
| 4 | /* ... Vos multiples PROC et DATA steps ... */ |
| 5 | PROC SORT DATA=sashelp.class out=class; BY age; RUN; |
| 6 | DATA _null_; SET class; RUN; |
| 7 | |
| 8 | /* Fin et calcul */ |
| 9 | %let end_time = %sysfunc(datetime()); |
| 10 | %let duree = %sysfunc(putn(%sysevalf(&end_time - &start_time), time8.)); |
| 11 | |
| 12 | %put NOTE: Durée totale du traitement : &duree; |
Los códigos y ejemplos proporcionados en WeAreCAS.eu son con fines educativos. Es imperativo no copiarlos y pegarlos ciegamente en sus entornos de producción. El mejor enfoque es comprender la lógica antes de aplicarla. Recomendamos encarecidamente probar estos scripts en un entorno de prueba (Sandbox/Dev). WeAreCAS no acepta ninguna responsabilidad por cualquier impacto o pérdida de datos en sus sistemas.