|
Question: Does the address of CmdStr point to the first byte of the two byte string length?
Yes.
If so, what rule tells the compiler that the unprototyped call to QCMDEXC is to have the address of the CmdStr parameter offset by the two bytes?
In spite of the fact that you used the phrase "unprototyped call to QCMDEXC" the code that you've posted uses the CALLP (call with prototype) opcode that ONLY works with prototypes.
Your prototype for QCMDEXC must have "CONST" defined on it. This allows the compiler to do conversions for you. So, it's converting from VARYING to non-varying by copying the data to a temporary variable (generated behind the scenes by the compiler) and passing THAT to QCMDEXC.
Would it be more efficient to define CmdStr with OPTIONS(*VARSIZE) instead of VARYING? Why?
VARYING is a data type. It means "an alphanumeric field where the first 2 bytes indicate the length, and the rest of the bytes contain the data"
OPTIONS(*VARSIZE) is a parameter keyword. It means "don't signal an error if the length of the variable that I've passed is smaller than the one on the prototype". In other words, it disables some of the compiler's validity checking.
As you can see, these aren't alternatives to one another. There might be times when you want to use both of them, there might be times when you want neither of them...
One thing in your code that DOES have a big impact on performance is the VALUE keyword on the prototype for Command(). It means that it'll make a copy of the parameter, rather than just using the copy from the caller. This hurts performance.
Likewise, since you're passing a different data type (VARYING) from the one that QCMDEXC needs (non-VARYING) the QCMDEXC call will have to make a copy of the data... and that will, again, hurt performance.
However, neither of those performance hits will be a very big deal. After all, copying memory is a fast operation on most computers.
There are a lot of other things besides the parameters that impact performance. For example, you've calling an extra subprocedure called Command() instead of calling QCMDEXC directly, that'll impact performance.
The very fact that you're using QCMDEXC instead of calling a CL module to run the commands affects performance. (QCMDEXC has to parse the string, a CL program does that at compile time.)
So there are several things that will improve performance, the question is, is it worth it? Are you calling this millions of times in a loop? If you're calling it only 100 times, you may not care about shaving off 1 millisecond from the call time. After all, the user probably won't notice that 1/10 second.
If performance is really that critical, consider writing your application in MI.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
