Performance and early/late binding
- From: Clark F Morris <cfmpublic@xxxxxxxxxxxxxxx>
- Date: Sat, 10 Oct 2009 23:30:16 -0300
There are some very interesting trade-offs among time of binding,
performance and maintainability. The situation is not as cut and
dried as it might seem. For example, IBM z series COBOL binds
virtually all of the system sub-routines including the I-O modules at
run-time for batch programs. Many shops including the three that I
have been at also had the default compile option for batch as DYNAM,
bind at run time. This has a slight but measurable cost in CPU time
for both the initial bind and for each call. The binding at compile
time of modules written in the same language (COBOL, C/C++, etc.) can
allow for very interesting optimizations. On the z/OS system the bind
needed to create an executable module (the compile produces executable
code that must be wrapped) cuts down on the inter-module overhead
versus execution time bind but doesn't eliminate it. While I have not
used OO, the requirement for parameter verification (something also
recommended by the SHARE/Guide Language Futures Task Force in the
1980's for calls) adds to the initial bind overhead. Remote Procedure
Calls would have even more overhead because of the communications
links. There are reasons why the World Wide Web is sometimes called
the World Wide Wait. In general it take resource to move data across
boundaries, especially when you add a communications link where the
speed of light matters and there are relay delays. As someone who
remembers 1200 baud dedicated lines where you could watch the data
flow on a monitor, the speed of my banking transactions amazes me
especially given that I am using an encrypted link. However this all
takes compute and communication time and both resources are finite.
Efficiency still matters although not as much. If you don't believe
it matters, then why did Microsoft put so much effort into improving
performance in Windows 7 and Norton have to put a major amount of
effort into improving the performance of their security programs. I
know that I am happier with both my e-mail package responsiveness and
web responsiveness since I upgraded from Zone Alarm 9 to Zone Alarm
10.
The other interesting question is when do you want the change in the
requested service to take effect. Early binding may be chosen so that
the change only takes effect when the requesting service is changed or
at least rebound. This option may be chosen so that testing can be
phased. Late binding means that changes and fixes are immediately
available which can sometimes lead to undesired results and also means
that the scope of prior testing may be large.
The situation becomes even murkier as more of our applications are
driven and controlled by external data tables be they in data bases or
random access files. The loading and referencing of this information
takes time. Despite these drawbacks, the terminal driven billing
system where I worked in 1969 was data table driven (ISAM later VSAM
file). Data entry to the tables was not rigorously checked.
Relatively little testing was done since we didn't have a simulation
or test system. I suspect that many organizations today that use data
tables are not as careful with the changes they put in production by
table entry changes nor are they as well controlled through promotion
mechanisms as program changes. I wonder how many fiascos have
occurred due to this and how many have never been known.
Performance, flexibility and control are all balancing acts.
.
- Follow-Ups:
- Re: Performance and early/late binding
- From: Pete Dashwood
- Re: Performance and early/late binding
- Prev by Date: OT: Workplace cultures WAS:Re: Period for qualification
- Next by Date: Re: Data compression
- Previous by thread: ~~~~~ POWER DVD ~~~~~
- Next by thread: Re: Performance and early/late binding
- Index(es):
Relevant Pages
|
