Date: Wed, 26 Sep 2001 11:39:47 -0400
Reply-To: "Diskin, Dennis" <Dennis.Diskin@PHARMA.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Diskin, Dennis" <Dennis.Diskin@PHARMA.COM>
Subject: Re: Speed of =: vs. SUBSTR()...
I don't mean to jump on you but this is an over generalization.
Not all functions are implemented as calls to programs, many compilers
implement some built-in function calls as in-line code depending on the
types of the arguments.
Conversely, just because something is coded as an operator, does not mean it
is implemented as in-line code. For example, exponentiation is generally
handled as a program call regardless of whether it is coded as an operator
or a function. Again, in this case some compilers will optimize the code
when one or more of the arguments are constants, especially if they are
> -----Original Message-----
> From: Gerhard Hellriegel [SMTP:ghellrieg@T-ONLINE.DE]
> Sent: Wednesday, September 26, 2001 11:18 AM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: Speed of =: vs. SUBSTR()...
> Simply, whithout testing: the operator =: has to be faster, because the
> implementation of an operator is can be much more efficient, than a
> function (subroutine) call (no parameter passing, always in memory because
> not much code, ...)! Otherwise I'd say, the implementation is stupid.
> The thing, that subsequent calls of a function sometimes is faster: the
> function is a peace of code, maybe located in a DLL. This has to be loaded
> in memory by the first call. If you have enough real memory the chance is
> good, that it rests in the real memory for a while and can be reused
> without loading again.