Date: Mon, 30 Sep 2002 09:29:29 -0700
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "David L. Cassell" <Cassell.David@EPAMAIL.EPA.GOV>
Subject: Re: how does word scanner tokenize single vs double quotes?
Content-type: text/plain; charset=us-ascii
Mauro Morandin <my_family_name@LIBERO.IT> replied [in part]:
> so why don't you write a small C program (even the most untalented
> of C code you could ever write) which reads or writes a 100MB file and
> compare it to the equivalent SAS program (the most efficient you can).
*My* experience is that it is insane to waste one's productive time
trying to get a piece of C code to handle all the necessary read/write
buffering to read and write large files which SAS handles far faster
say, COBOL already. Faster than Oracle too. If you can whip out C code
like that for dealing with really large files in a high-speed
then more power to you. I tip my hat to you.
> Even Python (which is a bytecode interpreter without a "Just in time
> compiler") does better than SAS.
I disagree. I haven't found Python faster in read/write. I can tweak
some Perl to read a small file faster than SAS can, but the Perl code
run into difficulties as soon as my files exceed usable memory. And
tweaking of the Perl code becomes counter-productive when the SAS code
is easier to write, easier to read, easier to maintian, and already
> The point is that you need some tough piece of equipment to get SAS go
> really fast. I've read on this newsgroup that SAS V9 will be able to
> just in time compiling (years behind Java).
But it is already *way* faster than Java, so there hasn't been the
hair-pulling need for JIT that there is in the Java world.
> Ever heard of a sysadmin who likes SAS??? Ever asked yourself why???
Actually, I haven't heard a sysadmin who was vehemently *opposed* to
I have met sysadmins who hated Oracle, MS products, etc., but I haven't
heard one railing against SAS.
> So why don't we agree on some simple facts:
> 1. SAS is an interpreter and thus much slower than any equivalent C
This only has to be true in settings where the C program can work in a
traditional manner. If you write a lightning-fast C program which, due
to the size of the files, ends up thrashing your virtual memory for a
time, it may not be as fast as you wanted.
Also, the speed of the algorithms underlying some parts of SAS,
the statistical aprts, can overcome a lot of speed advantages of the C
language. Will your C programmer write a matrix inversion routine which
is as fast as it can be, much less robust when the matrices are
They sure didn't for MS Excel, Lotus 1-2-3, ... (insert spreadsheet name
> 2. SAS is a very "powerful" framework for building applications, and
> thus it is possible to build bigger and more complex systems with
> lines of code, which means fewer bugs, fewer maintenance costs, faster
> product delivery.
> 3. There are many, many projects where point 2 is much more important
> than point 1.
> 4. We all prefer to write SAS programs rather than C programs.
I have a colleague who disagrees on point 4. But then, he thinks
is swell. :-)
David Cassell, CSC
Senior computing specialist