Date:         Tue, 29 Jan 2002 08:30:11 -0500
Reply-To:     Charles Patridge <Charles_S_Patridge@PRODIGY.NET>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Charles Patridge <Charles_S_Patridge@PRODIGY.NET>
Subject:      Comments on SAS Efficiencies

OK SAS-Lers,

I was asked the question this morning about what are your top 5 suggestions
on SAS efficiencies, and here is what I had to say - maybe some of you may
disagree which is why SAS-L is an excellent forum for such discussions.

And if you are willing to provide your two cents, I may even try to capture
all the $.02 worth of ideas and pack them into another Tip and Technique
page for SCONSIG.com <grin> - so share your thoughts and ideas on this
topic.

Dear Michael,

First, when I start to develop a new program, I make use of real data in
testing by using OPTIONS OBS=100 or so.  This keeps files small and still
allows me to test my code.

This is more development efficiencies than SAS efficiencies.

1.
Given the power of Proc SQL I will still use Data Step programming
techniques to sometimes overcome the inefficiencies of SQL.  You need to
benchmark both ways when dealing with large datasets.  Sometimes SQL will
outperform Data Step but then again, your Data Step logic may not be the
most efficient.

2.  I tend use Proc Format to do table lookups instead of merging files as
long as my lookups are not too large, say under 20000 records.

Also, look into using SAS arrays where possible as they can save a lot of
CPU.

3.  When dealing with large files and MANY variables - use the KEEP option
when reading SAS Datasets unless all the variables are needed later in the
process.

4.  Depending on the OS, you may have disk caching or read ahead features
in SAS that can be utilized.  Look at the SAS OS Companion Guide for your
OS platform to see if they exist.

5.  One efficiency technique I overlook (on purpose) is to use SAS views as
opposed to SQL PassThru when accessing external Databases.  I find
maintaining SQL Passthru code to be overburdening as opposed to little
maintenance on SAS Views (using ACCESS).  Again, here is an example that
SAS efficiency may cost you more in terms of maintenance costs than
execution costs.

6.  Try to design SAS programs using Table Driven System Designs as opposed
to making program changes.  It is easier to maintain tables than programs
even if it takes a little longer to execute your SAS code.  People costs
are expensive and real dollars as opposed to CPU costs (somewhat).  Plus
data/system integrity is critical for users as opposed to system running a
little slower.

7.
Finally, make sure everyone on your team understands the SAS techniques you
employ in your development.  What good does it do when you become the best
SAS programmer but you are the only one who knows how to maintain it?  Make
sure you share your knowledge with code walk throughs, quick SAS tutorials
over lunch or a brief meeting to explain the code.

BTW, having code walk throughs is a good idea for any major project
development as you go through unit testing.  This enables the team to
discuss different methods as well as convey SAS techniques to all team
members, and share what your piece of the system is doing - Excellent
Practice for all development (SAS or not).

Have to get back to work.  Hope this helps even though there can be many
other tips to offer as this topic.  You might consider soliciting the SAS-L
forum.

Regards,
Charles Patridge
--- Original Message ---

To: Charles_S_Patridge@prodigy.net
Subject: SAS Efficiencies Question

>Hello Mr. Patridge,

I am a SAS programmer and have been given the task of giving a presentation
 to my firm's SAS Users Group on the topic of SAS efficiencies.  I have
found much documentation on the subject and have many ideas for what I
believe is an efficient way to code.  However, I have a limited time (15
min.) in which to give this presentation and am stuck trying to define a
list of the top 5-10 "most efficiency for the buck".  I have seen and read
much of your SAS work and techniques on the Internet, so I am hoping you
can extend to me those efficiencies you feel are most important when you
write a program.

Any help you can provide would be much appreciated.

Sincerely,

Michael Hermeston