LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (February 2007, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Mon, 12 Feb 2007 09:43:53 -0500
Reply-To:     Michael Raithel <michaelraithel@WESTAT.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Michael Raithel <michaelraithel@WESTAT.COM>
Subject:      Re: Check it out--we're java programmers
In-Reply-To:  <CA8F89971ADA9F47A6C915BA2397844201EA76F1@MAILBE2.westat.com>
Content-Type: text/plain; charset="us-ascii"

Dear SAS-L-ers,

In one of the many replies to this interesting thread, Sig Hermansen posted:

> Interesting idea ... > I wish that the developers would avoid playing on old > misconceptions about compiled vs. interpreted programs: " ... > runtime speed (compiled Java runs at a significant multiple > of the speed of interpreted Base SAS(r))..." I can't imagine > that either compilation or interpretation of SAS programs > would save substantial amounts of time in any application. No > harm in illustrating a few examples of how compiling Java > programs leads to faster execution times, but global claims > based on flimsy technical support convince no one but the gullible. S >

Sig, I address the topic of "pre-compiling" SAS DATA Steps in Chapter 10, The Stored Program Facility, of my book, Tuning SAS Applications on the OS/390 and z/OS Environments, Second Edition. Though this book is aimed at SAS on the mainframe, people running SAS on other platforms can use the Stored Program Facility to pre-compile SAS DATA steps. Check it out in the SAS Online Documentation:

http://support.sas.com/onlinedoc/912/getDoc/lrcon.hlp/a000763412.htm

As I note in my book: unlike "traditional" languages that first compile program code into object modules, and then link edited the object modules into load modules, SAS:

1. loads SAS system modules into memory 2. compiles the source code into "intermediate code"--not an object module 3. turns control over to the instructions of the "intermediate code" to begin program execution

Because SAS programs "compile and go" in a single step, programmers are not burdened with having to go through the formal compile and link steps of many other languages. However, this means that a finished production program executed 1,000,427 times, must compile 1,000,427 times--a waste of computer resources if one looks at the big picture. Consequently, the SAS Institute developed the Stored Program Facility so that completed DATA steps could be compiled once and the intermediate code stored for repeated execution.

There are a couple of issues with the Stored Program Facility that have relegated it to the bottom of my own personal SAS toolbox. The first is that most of the wallclock time for a given DATA Step is consumed in processing data and doing the actual work specified by the DATA Step; not in compiling it. So, I usually do not save very much time by pre-compiling. And, it takes time, effort, and planning to pre-compile, store the program somewhere, modify programs to execute the pre-compiled DATA step, etc. All of this effort is usually not worth the savings I get.

Secondly, you don't really achieve significant run time reductions unless you have very big DATA Steps. Pre-compiling smaller ones doesn't usually save you very much in computer resources.

Without rehashing Chapter 10, the main considerations are:

1. The size of the DATA Steps 2. The number of DATA Steps in a program 3. The frequency of DATA Step execution 4. The volatility of the DATA Step (to being modified).

So, wrapping up this wordy contribution--fellow SAS-L-ers who are really interested in pre-compilation of SAS code should check out the Stored Program Facility. But, don't get your hopes up that it will lead to SAS Application Performance Nirvana!

All, best of luck with your SAS endeavors!

I hope that this suggestion proves helpful now, and in the future!

Of course, all of these opinions and insights are my own, and do not reflect those of my organization or my associates. All SAS code and/or methodologies specified in this posting are for illustrative purposes only and no warranty is stated or implied as to their accuracy or applicability. People deciding to use information in this posting do so at their own risk.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Michael A. Raithel "The man who wrote the book on performance" E-mail: MichaelRaithel@westat.com

Author: Tuning SAS Applications in the MVS Environment

Author: Tuning SAS Applications in the OS/390 and z/OS Environments, Second Edition http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172

Author: The Complete Guide to SAS Indexes http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ As long as you derive inner help and comfort from anything, keep it. - Mahatma Gandhi +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Back to: Top of message | Previous page | Main SAS-L page