Delayed Compilation and Execution in SAS: Is It Possible?

If you come from a traditional programming environment (like C, C++, or COBOL), you are used to a binary workflow: you write the code, compile it into an executable file (binary), and then execute that file later.

A question often asked by experienced SAS^© developers is: Is it possible to compile SAS^© code separately to execute it later, without having to recompile it at each launch?

The short answer is yes, but with important nuances. Here is what you need to know about SAS^©'s "Compile-and-Go" architecture and the methods to work around this behavior.

The Standard Model: "Compile and Go"

Unlike a COBOL program that generates a "load module," SAS^© traditionally operates on a "Compile and Go" model.

When you submit a program, SAS^© reads the code, checks it, compiles it into memory, and executes it immediately. For the vast majority of users, these two steps are invisible and simultaneous. However, there are mechanisms to separate these phases if your needs require it.

4 Methods to Store and Execute Pre-compiled Code

According to experts, here are the four main techniques for storing SAS^© code so that it can be executed later, thus reducing the compilation overhead at runtime.

1. SAS^© Macros (Stored Compiled Macros)

This is the most common method. Instead of recompiling your macro in each session, you can use Stored Compiled Macro Programs.

• The principle: You compile the macro once and store it in a permanent SAS^© catalog.

• The advantage: When called, SAS^© skips the compilation step and directly executes the instructions. This is managed via the MSTORED and SASMSTORE options.

2. Compiled DATA Step Programs

Few people know this, but you can compile a DATA step and store it for later execution.

• The principle: Use the DATA statement with the storage option to create a view or a stored program.

• The use case: This allows for executing complex data processing logic without rereading the initial source code.

3. SAS^© Stored Processes

If you work with the SAS^© Enterprise Intelligence platform, this is the modern solution.

• The principle: The code is stored in a central repository (metadata repository).

• Execution: The code is called on-demand by client applications (Excel, Web, EG). Although the code is often re-compiled on the fly by the server, the architecture allows for centralized management that mimics the deployment of executables.

4. SAS^© Enterprise Guide (EG) Projects

Although this is not "compilation" in the strict sense, an EG project freezes the logic of your tasks. Once developed, the process flow can be re-executed as is, automating the sequence without manual intervention or redevelopment.

Note for Mainframe users: On z/OS systems, there has historically been a specific SAS^©/C compiler, but this remains a very particular use case.

The Real Question: Should You Do It?

Just because you can do it doesn't mean you should do it.

Why Hesitate?

1. Minimal performance gain: On modern machines, the compilation time of SAS^© code is often negligible compared to the I/O processing time (reading/writing data). Pre-compiling will only save you a few milliseconds, unless your code is gigantic.

2. Maintenance complexity: Managing catalogs of compiled macros or stored programs adds a layer of complexity. If you lose the source code, you cannot easily "decompile" the result to modify it.

3. Risk of unexpected results: Improper use of stored macros can lead to behaviors that are difficult to debug if the execution environment differs from the compilation environment.

When Is It Useful?

The pre-compilation approach is recommended only for:

• sophisticated and critical applications.

• Environments where response time is vital and every millisecond of CPU counts.

• Protecting intellectual property (to hide the source code while allowing its execution).