Re: large difference in job run times between bound procedure call, and procedure call from within program.

Ali, not sure what you mean about using LR in a service program. No such
thing. Service program should be running in a named activation group and,
if possible, same activation group as the program.

Also, are you passing or returning large parameters. In your program, you
have them in a global space. In the service program you are passing, maybe?

Once the service program is loaded, should be no difference in performance
between procedure in service program and procedure in program assuming you
are talking apples to apples and not apples to oranges(Procedures don't
operate the same way).


On Wed, Aug 25, 2021 at 12:07 PM Ali Ekinci via RPG400-L <
rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:

here is my 2 cents:

* do not turn on LR in the procedure, have an initialization logic
that is processed only at the first call
* make sure your utility program is not using *NEW activation group.

________________________________
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Gerald
Magnuson <gmagqcy.midrange@xxxxxxxxx>
Sent: Wednesday, August 25, 2021 2:59 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: large difference in job run times between bound procedure call,
and procedure call from within program.

Sent by an external sender
------------------------------

I don't have my terms correct, sorry.

we have many programs that have a sub-routine, called "get allocations".
This routine is found in over a dozen of our programs, and trying to
simplify things, I made it a
procedure, and even migrated from f specs to complete SQL.

However, in a program that invokes this routine 300k times, the run time
went from 25 seconds, to
350 seconds to sometimes over 400 seconds.

If I put the procedure in the bottom of the program I call it, it runs as
fast as the sub-routine call.

maybe this is normal for the overhead of having a bound procedure call, or
maybe I just don't know what i need to do.
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com