I'm taking a routine that passes in as one of its arguments a dynamic array of indeterminate size and modifying it to take three arrays. I really can't say how large is 'large' as they will change in size from run to run and call to call but I don't think it would be anything I'd consider exceptionally large. So... anything to worry about, performance wise, ya think?
Large routine arguments
Moderators: chulett, rschirm, roy
Large routine arguments
Just wondering if I should be concerned about something.
I'm taking a routine that passes in as one of its arguments a dynamic array of indeterminate size and modifying it to take three arrays. I really can't say how large is 'large' as they will change in size from run to run and call to call but I don't think it would be anything I'd consider exceptionally large. So... anything to worry about, performance wise, ya think?
I'm taking a routine that passes in as one of its arguments a dynamic array of indeterminate size and modifying it to take three arrays. I really can't say how large is 'large' as they will change in size from run to run and call to call but I don't think it would be anything I'd consider exceptionally large. So... anything to worry about, performance wise, ya think?
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
ray.wurlod
- Participant
- Posts: 54595
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Nah. All arguments are passed by reference - that is, the address of the string in memory is all that's passed to the routine.
That was, of course, a slight lie. What is actually passed is a DATUM, an internal, 16-byte structure that includes the address and also other information about the string, such as whether a REUSE() function is in effect, the field mark "hint" position for REMOVE, and so on.
But it's a good enough explanation. The moral of the story is that huge strings are not passed.
That was, of course, a slight lie. What is actually passed is a DATUM, an internal, 16-byte structure that includes the address and also other information about the string, such as whether a REUSE() function is in effect, the field mark "hint" position for REMOVE, and so on.
But it's a good enough explanation. The moral of the story is that huge strings are not passed.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
