Ok, how about this.
1) don't rely on creating and using so many macro variables
2) Don't mix the use of regular SAS code with macro code
As an example of #2 (sort of, I can't share the code).
I had a macro that used a DATA step to read a file to extract information that the macro then returned as a single value: call symput("&dummy",value); . Whenever the compiled macro was executed, which injected SAS code which was then also compiled and executed, each time. I replaced that macro with a new one that was 100% purely macro code, which opened the file, used fetchobs to retrieve the desired value, and then "returned" the value: &&&&_&dummy; . Now, when executing the compiled macro, it is simply executed; there is not a second compilation step required.
Usage changed from
[pre]
%let userid = %getID;
%global password;
%getPWD(&userid,password);
[/pre]
to
[pre]
%let userid = %getID;
%let password = %getPWD(&userid);
[/pre]
While in this context the perform gain is not important, the principle still applies where it would be signficant.
Straight regular SAS code or straight macro code will always be faster.
The mixing of SAS and macro code should only be used to simplify the writing of SAS code: to provide a single point of maintenance, to modularize the code to reduce redundancy of effort, to parameterize commonly performed coding efforts.
I have found over my years of experience with SAS programming, that the finely intermingled coding efforts illustrated by your example can always be done better with proper use of regular SAS coding features, that the original coder really didn't understand SAS. I have been guilty of that many times myself.