> So the execution speed of the code does not change.
You're missing the point -
Sure, the compile time versus run time processing is a
factor, but the
fact of the matter here is not the EQUATE itself but the
data it is
equating to...
At compile time the compiler does not have access to the
contents of the
COURSE.SECTIONS dynamic array, and thus still only creates a
pointer
into an unknown array.
You want speed?
- Quick fix :
===========
Make the COURSE.SECTIONS dynamic into a dimensioned
array - each
position is then acted on as a separate variable,
directly
addressed.
- Longer, labour intensive fix, better in the long run
====================================================
Check the contents of the files referenced - is the
data dynamic
or
static? If it's static (eg code files that aren't
likely to
change,
or worse still, system variables that will never
change) why not
consider writing a program to create $includes that
"semi-hard
code"
the data so that at compile time the equate can insert
the
contents
of the variable into the object?
Any time the code files change you simply run the
proggie to
rebuild
the includes, and recompile the source. Alternatively
you could
get
the code file update routine to update the include
directly, and
flag
the relevant source for recompilation.
An example on our site is EQUATES to system variables
that, for
our
system, are never going to change. In terms of
portability this is
great, but we sacrifice speed. All this on a system
that is so
home-
grown that it'll never be ported...
- Leave the equate - it makes the code readable.
Readable = speed in maintenance terms.
-------
u2-users mailing list
[EMAIL PROTECTED]
http://www.u2ug.org/listinfo/u2-users
