Re: Low performance on varying length field

On Wed, 26 Nov 2003, Titus Kruse wrote:
> >     2) 65537 bytes of memory allocated for #RtnStr variable.
> I thought, that this would be done at program initialization of the calling
> procedure lately???

Every time the procedure is called, a new copy of #RtnStr is created.
That's the way subprocedures work, new copies of their local variables are
created each time they are called, and deleted when they end.  You can
declare a variable that's not re-built each time using the STATIC D-spec
keyword -- but creating a new variable doesn't take that much time.


> >     4) 65537 bytes of data are copied from #RtnStr to the caller's
>
> Why that?? When the storage for the return value is allocated before the
> procedure is called and only a few characters have to be returned?

Because the return value from a procedure is passed by value.  When
something is passed by value, it's contents must be copied.

That's why passing by reference is faster, you're giving the subprocedure
access to the caller's memory, and it can simply write the changes to that
space.  That prevents the need for making a copy of the data.

> I've debugged the calling procedure and set #str1 to a larger string then
> the test-string before my procedure was called. After returning from
> procedure 2 displaying field str1#  in hex-mode shows, that only bytes in
> length of the return-string are overwritten instead if 65535 bytes...

So, you're saying it's only copying the used portion of the 64k varying
string?   It still has to copy the data, though, even if it's only part of
the string...

> And....using a RPG builtin-function with long varying length fields doesn't
> need so much time to perform.

I don't know enough about how BIFs are written to address that.   I'm sure
someone else on this list can explain...