× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Sun, 2016-02-14 at 10:24 -0500, Jon Paris wrote:
On Feb 13, 2016, at 11:51 PM, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:

Jon,

Why would opdesc slow the process down? All opdesc does, under the covers, is pass a structure containing the lengths of the parameters. The time this takes shouldn't be significant. Do you know something I don’t?

Admittedly the overhead would be relatively low but the descriptors have to be built and subsequently retrieved by the called routine. In the case of a generic routine that is going to handle a wide range of types and lengths that makes perfect sense but in this case there are many simpler faster alternatives. I was basically trying to point out that it was overkill.

I'm guessing the descriptors are created at compile time, possibly as
constants or similar (it already knows what is being passed when it
pre-compiles), and just passes that along with the usual defined passed
parameter pointers; as a hidden pointer at run time.

The overhead would be in the initialisation/call of CEEDOD, although I
get the feeling that its not "a program/procedure/api" as such, but
rather a function which could possibly even be in-lined with very little
overhead as all it would have to do is just take the input parm number
and return a copy (or even link a "based" style pointer) of the
previously created "constants".

That said, there is nothing stopping the original design and
implementation, of ceedod, from being long winded and complex with a
massive overhead. It would be interesting to compare a opdesc/CEEDOD in
comparison with using an additional "length of data" (%size) parameter
to see which was quickest for the same functionality in the caller and
called - checking size, making sure size not exceeded, etc.


Also, the original example that Brad Stone posted in this thread had a variable named 'inputSize' in the parameter list. Isn't that the size of the variable, exactly what you are suggesting?

Agreed - I confess I had’t noticed it was there. Wonder why he wasn’t using it to avoid any issues. %Subst can be used on the receiver side if a truncated result is acceptable/required.


On 2/13/2016 10:57 AM, Jon Paris wrote:

Instead of opdesc (which will slow the process down) you could always
pass the actual length as an additional parm.


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.