|
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 mailing list archive is Copyright 1997-2025 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.