× 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.



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Larry Ducie
Sent: Thursday, November 01, 2007 10:03 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Is const really that much better than value?

Hi Charles,

<snip>
It's pretty simple really, the key thing to realize is that
in both cases not only are you passing the data in the
variable but you're passing the current length of the variable also.
</snip>

I understand that part. But I'm wondering more about the
actual mechanics of passing a varying string by value.
For example, if I have a PI for a 2500A varying parameter and
the caller passes a 32000A varying variable (containing the
string 'ABC') I now know this process will involve two data
copies. What I would like to know is whether both only copy 3
bytes. I would also like to know how the copies are performed
for a standard alpha parameter/variable pair. Would both
copies involve copying 2500 bytes or would the first
low-level copy try to copy the full 32000 bytes only to later
get truncated. I think Barbara said both would truncate for
the non-varying character. I'm hoping both would only copy 3
bytes too for the varying character. But I do wonder if the
first copy would still reserve 32000 bytes for the field only
to copy 3 bytes into it.



In that case, 1 copy need to be made.

The size of the copy will be 2500, since that's what the procedure expects to get.

<snip>

But my point is really concentrated on the overhead not
mentioned in the manuals. We 'know' const is more efficient
than value and we 'know' varying is more efficient than
non-varying but it all seems a little anecdotal.
Strange when we work in a real of picosecond precision. ;-)

The why is easy, when moving the data at runtime, the current length of the actual data is always
known.

Moving a 32768a to a 32768a requires 32768 bytes to be read then written.

Moving a 32768a VARYING to a 32768a VARYING, when there's only 100 characters in the variable,
requires only a 100 bytes to be read then written. Actually, it's 102 since the first two bytes
containing the length are moved too. Obviously allot faster.


I mean, when you sit down and explain to somebody WHY in some
situations using const is much more efficient than value you
find it difficult when you're not really sure why yourself.
You just 'know' it is better, and that just doesn't sound too
great as an explanation. At least I now have a better
understanding of the WHY part. It will help me sleep at night. :-)

Again, the why is easy.

With VALUE, a number of bytes equal to the defined size parameter is copied to the stack.

With CONST, only a 16 byte pointer is copied to the stack.

Note that for a VARYING parameter size = max possible length, not current length.

Per Barbara: Don't bother to think about temporary variables. You can't really optimize for it, and
the behavior today may change tomorrow.

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.