Compilation et Exécution Différée sous SAS : Est-ce possible ?

Si vous venez d'un environnement de programmation classique (comme C, C++ ou COBOL), vous êtes habitué à un flux de travail binaire : vous écrivez le code, vous le compilez en un fichier exécutable (binaire), puis vous exécutez ce fichier plus tard.

Une question revient souvent chez les développeurs SAS^© expérimentés : Est-il possible de compiler du code SAS^© séparément pour l'exécuter ultérieurement, sans avoir à le recompiler à chaque lancement ?

La réponse courte est oui, mais avec des nuances importantes. Voici ce qu'il faut savoir sur l'architecture "Compile-and-Go" de SAS^© et les méthodes pour contourner ce fonctionnement.

Le Modèle Standard : "Compile and Go"

Contrairement à un programme COBOL qui génère un "load module", SAS^© fonctionne traditionnellement sur un modèle "Compile and Go".

Lorsque vous soumettez un programme, SAS^© lit le code, le vérifie, le compile en mémoire et l'exécute immédiatement. Pour la grande majorité des utilisateurs, ces deux étapes sont invisibles et simultanées. Cependant, il existe des mécanismes pour séparer ces phases si vos besoins l'exigent.

4 Méthodes pour stocker et exécuter du code pré-compilé

D'après les experts,voici les quatre principales techniques pour stocker du code SAS^© afin qu'il soit exécuté plus tard, réduisant ainsi la surcharge de compilation au moment de l'exécution.

1. Les Macros SAS^© (Stored Compiled Macros)

C'est la méthode la plus courante. Au lieu de recompiler votre macro à chaque session, vous pouvez utiliser des Stored Compiled Macro Programs.

• Le principe : Vous compilez la macro une fois et la stockez dans un catalogue SAS^© permanent.

• L'avantage : Lors de l'appel, SAS^© saute l'étape de compilation et exécute directement les instructions. Cela est géré via les options MSTORED et SASMSTORE.

2. Les Programmes DATA Step Compilés

Peu de gens le savent, mais on peut compiler une étape DATA et la stocker pour une exécution ultérieure.

• Le principe : Utiliser l'instruction DATA avec l'option de stockage pour créer une vue ou un programme stocké.

• L'usage : Cela permet d'exécuter une logique de traitement de données complexe sans relire le code source initial.

3. Les SAS^© Stored Processes (Processus Stockés)

Si vous travaillez avec la plateforme SAS^© Enterprise Intelligence, c'est la solution moderne.

• Le principe : Le code est stocké dans un référentiel central (metadata repository).

• L'exécution : Le code est appelé à la demande par des applications clientes (Excel, Web, EG). Bien que le code soit souvent re-compilé à la volée par le serveur, l'architecture permet une gestion centralisée qui imite le déploiement d'exécutables.

4. Les Projets SAS^© Enterprise Guide (EG)

Bien que ce ne soit pas de la "compilation" au sens strict, un projet EG fige la logique de vos tâches. Une fois développé, le flux de processus peut être réexécuté tel quel, automatisant l'enchaînement sans intervention manuelle ni redéveloppement.

Note pour les utilisateurs Mainframe : Sur les systèmes z/OS, il existe historiquement un compilateur SAS^©/C spécifique, mais cela reste un cas d'usage très particulier.

La Vraie Question : Devez-vous le faire ?

Ce n'est pas parce que vous pouvez le faire que vous devez le faire.

Pourquoi hésiter ?

1. Gain de performance minime : Sur des machines modernes, le temps de compilation du code SAS^© est souvent négligeable par rapport au temps de traitement des I/O (lecture/écriture des données). Pré-compiler ne vous fera gagner que quelques millisecondes, sauf si votre code est gigantesque.

2. Complexité de maintenance : Gérer des catalogues de macros compilées ou des programmes stockés ajoute une couche de complexité. Si vous perdez le code source, vous ne pouvez pas "décompiler" facilement le résultat pour le modifier.

3. Risques de résultats inattendus : L'utilisation mal maîtrisée des macros stockées peut entraîner des comportements difficiles à déboguer si l'environnement d'exécution diffère de l'environnement de compilation.

Quand est-ce utile ?

L'approche de pré-compilation est recommandée uniquement pour :

• Des applications sophistiquées et critiques.

• Des environnements où le temps de réponse est vital et où chaque milliseconde de CPU compte.

• La protection de la propriété intellectuelle (pour cacher le code source tout en permettant son exécution).