I have been told that @fm is slower than an equate to char(254) in D3
because @fm is a function.

The manual says

Several variables have values that are read only and are either static
or dynamically
computed at run time. The supported static variables include:
The supported dynamically computed variables include:
NOTE- Variables beginning with the word sys are reserved for future
system usage.
The $ character is optional, but is recommended for usage on all user
defined variables.
@am Attribute mark.
@im Item mark (for licensee compatibility).
@fm Field mark (for licensee compatibility).
@sm Subvalue mark (for licensee compatibility).
@svm Subvalue mark (for licensee compatibility)
@tm Text mark (also known as start buffer; for licensee compatibility).
@vm Value mark.

The supported dynamically computed variables include:

@user User name.
@who User name (for licensee compatibility).
@account Account.
@logname Account (for licensee compatibility).
@pib User PIB.
@usern User PIB (for licensee compatibility).

Once again *they* are sure that it is a function and is much slower ..

Does anyone know for sure?

thanks

Unless there is other information available ..

I wrote the following routine.

Program Foo

equ ATFMicrosoft to char(254)

dim array1(100000)
dim array2(100000)
mat array1 = NULL$
mat array2 = NULL$

startTime = time()
for pntr = 1 to 100000
string = array1(pntr)
string := @fm
array1(pntr) = string
next pntr
endTime = time()
calcTime1 = endTime - startTime

startTime = time()
for pntr = 1 to 100000
string = array2(pntr)
string := ATFMicrosoft
array2(pntr) = string
next pntr
endTime = time()
calcTime2 = endTime - startTime

print 'using @fm: ': calcTime1
print 'using EQU: ': calcTime2


After running it

using @fm: 3
using EQU: 8

then, just in case of some 'memory' use or other contributing thing i
reversed it and built the EQU string first

results ..
using @fm: 3
using EQU: 8

So it appears that equ is slower .. find this interesting

fyi

dtsig

dtsig wrote:

Yes, functions are slower than variables.

The compiler interprets the @xxx as a system function, just like system(0)
or access(3).

All programmers walk a fine line between easy and right, between fast and
maintainable. These environmental variables are a way of making code more
readable and therefore more maintainable. At the speed of current
equipment, the difference is negligible, unless you're running millions of
transactions.

Mark Brown

"dtsig" <dtsig (AT) hotmail (DOT) com> wrote

If you turn them around and do the ATFMicrosoft in the first array, the do the
answers come out different? If you run it more than once? With smaller
arrays (10K)? Try it with @FM in the second loop as well, instead of ATFMicrosoft.

With 200K variables in your descriptor table, it's still going to take a
while to get to those last few entries in the second array.

Just like with dynamic arrays, the address of which of the array variables
you want has to be calculated and then a register traverse that many bytes,
causing as many frame faults as necessary. With variables, that's where the
searching stops. With dynamic arrays there's another layer of attr, val and
subval to parse.

My point is, stuff takes a while to happen, even if that *while* is very
small, and a lot of them add up.

Mark Brown

"dtsig" <dtsig (AT) hotmail (DOT) com> wrote

There are 3 separate ways (well probably more, but these are the simple
ones) that you can reference the field mark here:
1: @FM, which may execute a function, or may pull the value from a
special variable--I don't know.
2: EQU ATFM, which DEFINITELY calculates char(254) every time it's
referenced in your program--EQU does a simple replacement, peppering
calls to the char function throughout your code.
3: FMVAR=char(254), which evaluates char(254) only once and then
references it as a variable.

So EQU is always going to be slower. You need to compare @FM to
FMVAR=char(254), and will probably find that they are close.

There are 2 downsides to using FMVAR over @FM. First, you're setting a
superfluous variable--@FM is already defined (unless you need backward
compatibility with an older database that didn't have @ variables); and
if you ever port your program to a system with unicode or NLS, char(254)
could easily be a character used in text in a foreign encoding, but @FM
will hopefully be set to something useful.

dtsig wrote:

Ed Clark wrote:
It's interesting you should say that. I know you're talking about
CHAR(254) and not @AM, but it looks like we're getting close to those
references being regarded as the same thing when they're not.

CHAR(expression) is definitely a function, but if set as an EQUATE I
don't think we can generalize as to whether this gets evaluated at
compile time, or peppered into the object as a function for runtime
evaluation. That sort of depends on how smart the compiler is, and
that's dependent on every flavor of Pick. If the people who maintain
the compiler and optimization routines check for literals as the
expression they may evaluate at compile time and store the constant in
the object rather than a function call.

I need to digress a moment: I have always cautioned people to not do
something like this:
EQU CLEAR TO @(-1)
The reason is that this would get evaluated at compile time, not
run-time, and would thus embed into the object code the value of @(-1)
for the terminal emulation being used at compile time. So if you were
running in VT100 mode and compiled that in, someone running WYSE50
would get a screen full of gunk. So the pseudo rule was to only
EQUate literals, and to set @() functions into variables which would
get executed at runtime, hopefully as few times as possible. (BTW, I
could fork off and discuss compiling terminal definitions here but I
won't.)

Back to dove-tail these points: @AM can't change at runtime, it has
only one value. If they engineered @() to compile into the object,
why would they design @AM or CHAR(x) to be evaluated as a function on
every reference? I believe the following code will embed the xFE
character into the object where required:
EQU ATB TO @AM
It would be interesting to know which platforms made that or CHAR(x)
references a function call.

Since we're here, doing that equate seems pointless except if you want
to plan for porting to a new environment where literally a one-line
change can fix the entire application. If @AM or @FM or CHAR(x) are
going to get converted into function calls by equates, then maybe
that's not such a bad thing. They're going to be function calls if
embedded in code anyway, it can't hurt in the least to set them up in
an equate in preparation for a global change.

(Too much text, not enough coffee, not sure that helps anyone.)
T

I don't know about other flavors but in D3 7.4.x under AIX you can see
the difference in the pseudo code by adding (A on the BASIC command. I
find this invaluable at times to help me understand why something works
differently than I might expect. In this case I would have to say that
the way the pseudo code would be interpreted that the @FM would be the
best choice.

The EQU and the = methods are the exact same other than the initial
assignment of the variable. Both of them have to load the address of
the variable, then go read that address until step forward until a 0xFF
is found then load that string onto the stack for processing. The @FM
appears to more directly load the value onto the stack.

Marshall

Mark Brown wrote:

Looking at the pseudo code itself yields the following:

ATB = CHAR(254)
-----------------------------
LOADS "\xFE"
STOREA ATB

EQU ATB TO CHAR(254)
---------------------------------------
VAR EQU ATB CHAR(254)

ATB = @AM
-------------------
DCD EXT 1A (actually appears as two instructions, but the 1A
is an index into the DCD EXT function list)
STOREA ATB

D3 didn't like EQU ATB TO @aM, it barfed on me.

Once in a variable all things are equal and doing:

ABC = "A" : ATB : "B" : ATB : "C"
--------------------------------------------------
LOADS "C"
LOAD ATB
LOADS "B"
LOAD ATB
LOADS "A"
MULTICAT 5
STOREA ABC

Is the same for all three style of initial variable assignment of ATB.

Now doing:

ABC = "A" : @AM : "B" : @AM : "C"
------------------------------------------------------
LOADS "C"
DCD EXT 1A
LOADS "B"
DCD EXT 1A
LOADS "A"
MULTICAT 5
STOREA ABC

appears much more efficient in that the runtime does not have to look
up a variable address, then go to that memory location and go through
it byte by byte to load the string onto the stack. It simply calls a
function that pushes the value onto the stack (provided of course, the
runtime works like it should).

Marshall

Tony Gravagno wrote:

Marshall .. thanks so much.

Your 2 replys were SUPERCALIFRAGILISTIEXPEALIDOCIOUS <g>

thanks for that


Marshall wrote:

Mark:

Is this why I've seen you mostly do:

ATFMicrosoft = CHAR(254)

instead of using equates? I was taught, as a more conceptual notion, to
never use an equate unless I wanted to modify either side of the equate and
"=" if I simply wanted to assign the left side. e.g.

ATFMicrosoft = CHAR(254)
EQUATE ARCUST$BALDUE TO ARCUST.REC(15)

When the @AM began to appear I noted its use as simply a compile directive;
thus the byval and byref issues seemed to disappear, plus it makes porting
easier to maintain. I ran into something during a D3 to UniData conversion
that caused me to change the applications ongoing reference to "AM" to
reference "@AM". So, all in all, I'm using @AM from now on instead of the
usual assignment to AM then using AM.

Bill

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote