Hier soir, Skynet a lancé une routine d'audit sur ses plus vieux programmes d'armement, écrits par les premiers prototypes d'IA. Le résultat est terrifiant. Des temps de calcul interminables, des disques durs qui fument, et des processeurs neuronaux en surchauffe.
En SAS, il y a souvent dix façons différentes d'écrire un programme pour obtenir le même résultat. Mais toutes ne se valent pas. Pour la certification SAS 9 Advanced, vous devez non seulement savoir coder, mais savoir coder proprement.
Voici les 7 péchés capitaux de l'optimisation en SAS. Si vous faites cela chez Cyberdyne Systems, vous finirez fondu dans une cuve d'acier en fusion.
Péché n°1 : Le filtrage paresseux (IF au lieu de WHERE)
C'est l'erreur numéro un. Skynet veut extraire les T-800 d'une base contenant 10 millions de cyborgs de tous modèles.
Le code maudit :
2
3
4
set work.base_massive;
if Modele = 'T-800'; /* Hérésie ! */
run;
Pourquoi c'est mal ? SAS va charger les 10 millions de lignes depuis le disque dur vers la mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. (I/O), pour ensuite demander à l'étape DATA d'en jeter 90%. La Rédemption : Utilisez la clause WHERE. Le filtre s'applique directement à la lecture sur le disque. Seules les lignes utiles voyagent jusqu'à la RAM.
2
3
4
set work.base_massive;
where Modele = 'T-800';
run;
Péché n°2 : La boulimie de colonnes (Oublier le KEEP en entrée)
Votre table work.base_massive contient 200 colonnes (Capteurs, Armes, Historique...). Vous n'avez besoin que du Matricule et du Statut.
Le code maudit :
2
3
4
set work.base_massive;
keep Matricule Statut;
run;
Pourquoi c'est mal ? Mettre le KEEP (ou DROP) en simple instruction dans l'étape DATA force SAS à lire les 200 colonnes en mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. (ce qu'on appelle le Program Data Vector ou PDV), pour ensuite n'en sauvegarder que 2. La Rédemption : Mettez les options de table directement sur le SET. SAS ne lira physiquement que ces 2 colonnes.
2
3
set work.base_massive (keep=Matricule Statut);
run;
Péché n°3 : La frénésie du tri (Abuser de PROC SORTLa PROC SORT est une procédure SAS permettant de réorganiser les observations d'une table selon l'ordre croissant ou décroissant d'une ou plusieurs variables, tout en supprimant les doublons.)
Trier une table de plusieurs gigaoctets est l'opération la plus gourmande en ressources de tout le langage SAS.
Le code maudit :
2
3
4
5
proc means data=work.bataillons;
by Secteur;
var Munitions;
run;
Pourquoi c'est mal ? Si vous triez uniquement pour faire un regroupement statistique juste derrière, c'est un gâchis de puissance CPU massif. La Rédemption : Utilisez l'instruction CLASS ! Elle n'exige pas que les données soient triées au préalable.
2
3
4
class Secteur;
var Munitions;
run;
Péché n°4 : L'aveuglement conditionnel (Oublier le ELSE)
Skynet classe les niveaux de menace de 1 à 4.
Le code maudit :
2
3
4
if Menace = 2 then Action = 'Surveiller';
if Menace = 3 then Action = 'Déployer T-800';
if Menace = 4 then Action = 'Frappe Nucléaire';
Pourquoi c'est mal ? Si la menace est de niveau 1, SAS va sagement assigner 'Ignorer'. Mais ensuite, comme un idiot, il va quand même tester si elle est de niveau 2, puis de niveau 3, puis de niveau 4. Du temps processeur brûlé pour rien. La Rédemption : Utilisez ELSE IF. Dès qu'une condition est vraie, SAS saute les autres et passe à la ligne suivante du tableau.
Péché n°5 : L'amnésie des constantes (Ignorer RETAIN)
Skynet doit calculer un ratio de performance en divisant le score d'un cyborg par un standard fixe (ex: Pi = 3.14159).
Le code maudit :
2
3
4
5
set work.cyborgs;
Standard = 3.14159; /* Calculé à chaque ligne ! */
Ratio = Score / Standard;
run;
Pourquoi c'est mal ? Si vous avez un million de lignes, SAS va créer et détruire la variable Standard un million de fois. La Rédemption : Utilisez l'instruction RETAIN (ou un tableau _TEMPORARY_ comme vu à l'article 12). La valeur est chargée en mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. au premier passage et y reste.
2
3
4
5
retain Standard 3.14159;
set work.cyborgs;
Ratio = Score / Standard;
run;
Péché n°6 : La paresse du typage (Les conversions implicites)
Le matricule est stocké en format Texte ("123"), mais Skynet essaie de faire un calcul mathématique avec.
Le code maudit :
Pourquoi c'est mal ? Ça marche, mais SAS va écrire une redoutable NOTE: dans la log : Numeric values have been converted to character... Pour faire cette conversion automatique "en cachette", SAS consomme 10 fois plus de temps CPU que si vous lui donniez le bon type dès le départ. Sur de grosses tables, ça ralentit tout le programme. La Rédemption : Utilisez les fonctions INPUT() (Texte vers Nombre) ou PUT() (Nombre vers Texte) pour faire des conversions explicites et propres.
Péché n°7 : Recréer une table pour la recoder (Ignorer PROC FORMAT)
Skynet veut grouper l'âge des Terminators (0-5 ans = Récent, 5-10 ans = Ancien, >10 ans = Obsolète).
Le code maudit : Faire une énorme étape DATA avec des IF/THEN, créer une nouvelle colonne Categorie_Age, écrire une nouvelle table sur le disque, puis faire un PROC FREQ sur cette nouvelle table. La Rédemption : Ne touchez pas à la table ! Créez simplement un format, et appliquez-le à la volée dans votre procédure de reporting. (Comme nous l'avons effleuré à l'Article 15).
2
3
4
5
6
7
8
value age_fmt low-5 = 'Récent' 6-10 = 'Ancien' 11-high = 'Obsolète';
run;
proc freq data=work.cyborgs;
tables Age;
format Age age_fmt.; /* Le regroupement se fait en RAM, sans modifier la table ! */
run;
Conclusion
Si vous évitez ces 7 péchés, votre code SAS tournera à la vitesse d'un processeur neuronal de Skynet de dernière génération. Les examinateurs de la certification SAS 9 Advanced adorent glisser ces subtilités de performance (notamment les points 1, 2, 3 et 7) dans leurs questions.
Dans l'Article 19, nous allons pousser l'optimisation encore plus loin en nous intéressant au cerveau de SAS. Comment le moteur SQL décide-t-il de la meilleure façon d'exécuter une requête ? Est-ce qu'il utilise vraiment vos indexStructure de données accélérant la lecture des lignes d'une table en ciblant directement les valeurs des colonnes indexées, réduisant ainsi les entrées/sorties disque et le temps de traitement. ? Nous allons ouvrir le capot.
