Date:         Mon, 30 Sep 2002 09:29:29 -0700
Reply-To:     Cassell.David@EPAMAIL.EPA.GOV
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
piece
> 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
than,
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
environment,
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
will
run into difficulties as soon as my files exceed usable memory.  And
further
tweaking of the Perl code becomes counter-productive when the SAS code
is easier to write, easier to read, easier to maintian, and already
faster.

> 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
do
> just in time compiling (years behind Java).

But it is already *way* faster than Java, so there hasn't been the
frantic,
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
SAS.
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
program.

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
long
time, it may not be as fast as you wanted.

Also, the speed of the algorithms underlying some parts of SAS,
particularly
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
ill-conditioned?
They sure didn't for MS Excel, Lotus 1-2-3, ... (insert spreadsheet name
here).

> 2. SAS is a very "powerful" framework for building applications, and
> thus it is possible to build bigger and more complex systems with
fewer
> 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
assembler
is swell.  :-)

David
--
David Cassell, CSC
Cassell.David@epa.gov
Senior computing specialist
mathematical statistician