Reginald - overhead of INTERPRET

Often, there is more than one way to write code to achieve
the desired result.
I have one routine where I may use a rather long SELECT or
an INTERPRET.
Is there a significant overhead incurred when using INTERPRET?

Daniel B. Martin

On 27 Mrz., 10:59, "Daniel B. Martin"
<daniel88b88mar...@earthlink88.net> wrote:
> Often, there is more than one way to write code to achieve
> the desired result.
> I have one routine where I may use a rather long SELECT or
> an INTERPRET.
> Is there a significant overhead incurred when using INTERPRET?
>
> Daniel B. Martin

in my experience: no! In my understanding the interpretation will just
performed twice on the statement.
E.G.:
VARNAME=FRED
interpret varname=47

lead to the following sequence:
interpret varname=47

now complete

E.G.:
VARNAME=FRED
interpret varname=47

lead to the following sequence:
interpret varname=47 
now step 2 is performed re-execute the result FRED=47 

I think the performance of this process is pretty much the same as
having 2 set statemtents in sequence. This is what I experienced.

Regards

Peter

PeterJ <Peter.Jacob@asg.com> wrote:

> now complete
>
> E.G.:
> VARNAME=FRED
> interpret varname=47
>
> lead to the following sequence:
> interpret varname=47 
> now step 2 is performed re-execute the result FRED=47 
>
> I think the performance of this process is pretty much the same as
> having 2 set statemtents in sequence. This is what I experienced.

It's pointless using interpret to assign a value to a variable, that's what
the value() function is for.

Interpret might be more useful if, say, some code builds a string of
statements to do something, and then you execute it, eg:

code = "a=7;b=5;c=" || gencode(33) || "; say a b c"
interpret code


--
Jeremy C B Nicoll - my opinions are my own.

Jeremy Nicoll - news posts wrote:
> PeterJ <Peter.Jacob@asg.com> wrote:
> 
>
> It's pointless using interpret to assign a value to a variable, that's wha
t
> the value() function is for.
>
> Interpret might be more useful if, say, some code builds a string of
> statements to do something, and then you execute it, eg:
>
>   code = "a=7;b=5;c=" || gencode(33) || "; say a b c"
>   interpret code
>
>

I love INTERPRET, except that it's much harder to debug than ordinary
REXX code.  (Trace ?i inside a loop in an interpret string is really
entertaining.)  The place I've used it most is in the front end script
to a big electromagnetic simulator, where I pre-evaluate some long
algebraic expressions, and use INTERPRET to put in the values (which can
be pre-evaluated expressions themselves, hence the need for INTERPRET).

I'm told that Perl has a similar facility, and it's certainly one of the
things that has made REXX such a good fit for the sort of stuff I
generally do--I wouldn't want to code that expression handler in C,
that's for sure.

Cheers,

Phil Hobbs

>Daniel B. Martin
>Is there a significant overhead incurred when using INTERPRET?

I try to avoid INTERPRET because, as Phil points out, it can make debugging 
a
little more difficult. Reginald's IDE tries to make it easier by actually
presenting the interpreted REXX instructions in a new editor window and lett
ing
you step through them one at a time. So debugging an INTERPRET statement is
pretty much the same as debugging a subroutine call in Reginald's IDE. But i
f
you have subroutine calls inside the interpret string, it can start to get
confusing as to where you are. (NOTE: Reginald's version of INTERPRET is vas
tly
enhanced, and let's you have labels, subroutines, error handling, and pretty
much any legal REXX instruction). So wherever it can be done without INTERPR
ET,
that's the way I prefer to do it.

Most uses of INTERPRET seem to be employed in order to work around having to
hard-code specific variable names, or deal with variables whose name you don
't
know until the script actually runs.

As Jeremy points out, you definitely should use VALUE() to assign a value to
 a
variable whose name you don't know ahead of time, rather than using INTERPRE
T.

Also, note that the USE ARG statement lets you create subroutines that are m
ore
generic, and don't rely upon hard-coded variable names.

INTERPRET occurs a little more overhead in running your script because
instructions have to be "parsed" every time the INTERPRET instruction happen
s.
In normal REXX code, the parsing is done once when a script is loaded, and s
o
even if a particular line is executed more than once, it still is parsed onc
e
only. But if your INTERPRET statement is not in a loop, and therefore execut
es
once only, that involves parsing two items -- the INTERPRET statement itself
,
and then whatever is being interpreted. You're typically not going to see a 
big
speed penalty in such a situation (ie, one item parsed per instruction, vers
us
two items parsed).

But note that Reginald adds a whole lot of extensions to give you many optio
ns
for speed and simplicity. If you're looking for the fastest possible code, a
nd
you like to keep your code in separate REXX scripts, then you may want to
investigate putting those scripts into a macro DLL. Then you'll load the mac
ro
DLL at the start of your main script. This is akin to "in-lining" all of tho
se
external scripts as if they were internal subroutines, and the speed differe
nce
is accordingly faster.

There are lots of other features that may be useful when you're exploring sp
eed
and simplicity of design. Definitely read the online help book "The REXX
Language", which also details many of these additional extensions.

>Phil Hobbs
>I pre-evaluate some long algebraic expressions, and use INTERPRET to
>put in the values (which can be pre-evaluated expressions themselves,
>hence the need for INTERPRET).

I'm not sure exactly how you're coding this, but if the point is to be able 
to
reuse the code upon several different variable names, you may want to look i
nto
USE ARG. It could be faster, and it should definitely be easier to debug.