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


  • Subject: Re: Efficiency of Bound vs. Dynamic Calls
  • From: "Eric N. Wilson" <doulos1@xxxxxxxx>
  • Date: Wed, 8 Sep 1999 18:11:57 -0700

Dynamic calls are just that (Dynamic) calling a ILE program dynamically
incurs the same penalty as calling an OPM program. (Possibly worse I have
not benchmarked this personally.) Any dynamic call has to do name resolution
(Find the program), then load the program into memory,  do any address
fixups, then initialize static storage, do implicit file opens, call any
*INZSR and then jump to the mainline code.  If the program sets on LR then
you will get to do the same steps over and over and over each time you call
the program. If you leave LR off then you have to go through the
initialzation subroutine forward.

If you were to bind to the module statically you do not have any of the
above steps incurred other than static storage initialization forward.

If you were to bind to a service program then you would incur (One time
only) name resolution, load the service program into memory, do memory
fixups, initialize static storage. This assumes the service program was
created with ACTGRP(*CALLER), Please always consider using this on service
programs (And never never never use *NEW which would cause a whole new
activation group to be created [which is nearly as expensive as starting a
whole new job]).

Note: I probibly do not have the exact order of the processes correct and
have most likely missed several.

Statically bound procedures will always be the fastest but will cause you
alot of grief when you change a module and have to go hunt all the programs
that use that module down and recompile (or updpgm).

Binding by reference is almost as good (binding to a service program)
speedwise as the cost of loading the service program is incurred once at the
beginning of the execution of the program and then the calls to the
procedures are nearly or as fast as a bound call. Maintenance of service
programs is dramatically easier than hunting down all the programs that use
a specific module. (You should consider using the binder language so that
when you end up adding functions to a service program you will not have to
worry about signature problems)

Dynamic calls are the ultimate in flexibilty and for that carry the greatest
penalty in performance.

Hope that helps
Eric

______________________________________________
Eric N. Wilson
President
Doulos Software & Computer Services
2913 N Alder St
Tacoma WA 98407


----- Original Message -----
From: <Norman.Rae@mckhboc.com>
To: <RPG400-L@midrange.com>
Sent: Wednesday, September 08, 1999 11:19 AM
Subject: Efficiency of Bound vs. Dynamic Calls


>
>
>
>
>      Hello all
>
>      I'm sure this issue has been covered here before, but as a newbie to
>      the list, I'd appreciate any help.
>
>      At my current place of employment they have created an ILE-RPG
program
>      to handle date manipulation, and standards state that this program
>      must be used or all date manipulations.
>
>      From OPM programs (which most of them still are), a regular CALL with
>      parameter list is performed.  However I was surprised to see that in
>      new ILE-RPG programs, they were still using a regular CALL.
>
>      I suggested that a CALLB (bound call) would be more efficient.  They
>      agreed, but stated that a dynamic call to an ILE program was quite
>      efficient, so much so that making it a bound call would not gain
>      enough to make it worth while dealing with the additional
>      complications that this would entail.
>
>      This didn't seem right to me, but I don't have any information to
back
>      me up.  Anyone got any thoughts on this matter?
>
>      Thanks ....Norman
>
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.