Re: How can I Improve this procedure...

Is this the same with the parameters passed to a procedure by Value.

Eg: myProc('hello')

D myProc        PI
D     parm1                    10 a Value


In the above example, is 'Hello' copied twice?
1. once from 'hello' --> 1024A work field
2. from 1024A (work field) --> parm1

Thanks
Praveen


On 4/19/06, Bob Cozzi <cozzi@xxxxxxxxx> wrote:
>
> A return value that is not an Integer or a Pointer is specified on the
> RETURN
> opcode.
> The system copies that to a work field that is the size and shape of the
> definition of the return value itself. So if you return a 10a field to a
> return
> value that is 1024a that 10A value is copied to a work field that is
> 1024A.
> Then that 1024a workfield is copied to the expression in which is it used.
> This
> is a second copy for which you have no control over.
> So now you've got data being copied twice, at minimum.
> If you do something like
>
> mycharVar = myProc('hello')
>
> and myProc returns that 1024a value, it now has to copy the second
> work/temp
> variable's value to the mycharVar field. So that's 3 copies.
>
> Why are long return parameters slow? Because they are copied (typically)
> at
> least 3 times and no fewer than twice.
>
> -Bob Cozzi
> www.RPGxTools.com
> RPG xTools - Enjoy programming again.
>
>
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
> On
> Behalf Of praveen gunda
> Sent: Wednesday, April 19, 2006 2:38 PM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: How can I Improve this procedure...
>
> Scott,
> "However, if the problem is that you don't believe me, you can wait until
> an IBMer on the list replies."
>
> I always like the explanations you give. It thows a lot of light on the
> subject. You give excellent replies.
> That is one reason I dare to ask questions in this forum. I get excellent
> replies from very experianced people here.
>
> One reason I asked for references is, so that I can convince others if
> they
> question me.
>
>
>
>
>
> On 4/19/06, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:
> >
> >
> > > can you elaborate on this? I keep hearing it very often but did not
> find
> > > much explantation as to why?
> >
> > Because a return value copies the data from one place to another.  So if
> > you return 3000 bytes, the system has to copy all 3000 bytes from one
> > place in memory to another place in memory.
> >
> > By contrast, when you pass a parameter (unless you use the VALUE
> keyword)
> > the system references the existing copy of the data in memory. It
> doesn't
> > have to copy it from one place to another, it just uses the original
> spot.
> >
> > > Is this the case with procedures too? Also is it any different if the
> > > procedure is in a service program?
> >
> > Since programs can't return a value, this discussion ONLY applies to
> > procedures, and that's what we've been talking about all along. Unless
> I'm
> > misinterpreting the question?
> >
> > No, it doesn't matter if the procedure is in a service program. (or
> > anywhere else)  This has to do with how parameters and return values
> work.
> > It doesn't matter where the procedures are located.
> >
> > > Is it not just a pointer that is returned? Any pointers to books/IBM
> > > resources on this topic will be helpful too.
> >
> > No, it is not a pointer that's returned.   I'm sure that there are IBM
> > resources that explain this, but I don't know what they are off the top
> of
> > my head.  I learned this stuff years and years and years ago, and I'm
> > afraid that I can no longer remember where I originally learned it.
> >
> > However, if the problem is that you don't believe me, you can wait until
> > an IBMer on the list replies.
> >
> > >>       D                 DS
> > >>       D ReasonDS                            dim(200)
> > >>       D  @RsnCode                      2A   overlay(ReasonDS:1)
> > >>       D  @Charge                       9P 2 overlay(ReasonDS:*NEXT)
> > >>       D  @Weight                       9P 0 overlay(ReasonDS:*NEXT)
> > >>       D  @Units                        7P 0 overlay(ReasonDS:*NEXT)
> > [SNIP]
> > >
> > > In this case does RPG allow  %lookup('XX': @RsnCode)  ?  I guess not
> as
> > > @RsnCode is not an array.
> >
> > Sorry, @RsnCode *is* an array, and yes you can use %lookup() on it.
> > That's the reason I suggested this technique.   The reason that it's an
> > array is because it's overlaying ReasonDS which is an array.
> >
> > [SNIP]
> > >>       D ReasonDS        ds                  qualified dim(200)
> > >>       D  @RsnCode                      2A
> > >>       D  @Charge                       9P 2
> > >>       D  @Weight                       9P 0
> > >>       D  @Units                        7P 0
> > [SNIP]
> > > This is exactly what I meant to do, but for the lack of %lookup
> support.
> > > Would it be possible to write a generic procedure, you can pass an
> array
> > > (could be an array of datastructure) that could look up this array...
> I
> > am
> > > just thinking loud here.
> >
> > You could write a subprocedure that loops through it and compares the
> > elements.  That way, you can call that subprocedure to do a lookup.
> >
> > Alternately, you could use the qsort() and bsearch() routines from the
> ILE
> > C runtime.  This has been discussed many times before, so searching the
> > archives should yield some examples.
> >
> > Of course, the overlay approach allows you to use %LOOKUP so you might
> not
> > even want to use the qualified DIM DS approach.  I'm just telling you
> what
> > your options are.
> >
> > --
> > This is the RPG programming on the AS400 / 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.
> >
> >
> --
> This is the RPG programming on the AS400 / 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.
>
>
> --
> This is the RPG programming on the AS400 / 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.
>
>