| Chuck Stevens 2005-07-25, 10:01 pm |
|
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3k86utFl4gssU1@individual.net...
>
> Yes, necessarily. :-) Three factors affect online performance; two of
them
> are load time and capture time. The smaller and tighter a module is, the
> quicker it loads and it will be likely to require less capture time.
Can you define a "module" of, or containing, COBOL code in an
implementation-independent manner?
I know of COBOL compilers that pay virtually no attention to natural
boundaries within a program when deciding where a block of object code
begins and ends, and I know of others on the same platform that allow the
user tight control over the size and end points of the object code segments.
The debate continues to rage over which approach is superior (I happen to
prefer the latter).
> Capture time for a process will be improved if there is less code for the
> process to execute (as long as it provides the same functionality, of
> course.)
It is not clear to me that making the particular piece of code smaller by
eliminating some in-line code and putting it into another piece of code will
always make it run faster. It seems to me that a "branch-and-link" or
other PERFORM analog to a sequence of machine instructions will ordinarily
run a little *slower* than the same sequence of machine instructions
executed linearly within the larger sequence. Maybe I don't understand what
it is you're trying to convey.
> Adding code cannot possibly make it execute any faster than it is required
> to. And if everything else is equal, the faster load time of a smaller
> module makes overall execution quicker.
OK, presuming the "module" needs to be loaded more than once during the
execution of the program ... a matter of a cost/benefit tradeoff on the
available memory on the system, ISTM.
>If a small module is being paged in
> and out continually, as opposed to a large resident piece of code,
Why should object code *ever* need to be paged *out*, since code can never
be modified in memory anyway?
If the system needs the memory space for a code segment, basically all it
needs to do is mark it absent in the segment dictionary, and take the
memory. Next time that code segment gets "touched" during execution, the
system will find space for it somewhere and load it back in. If that
reaches a point commonly called "thrashing", it's time to take action --
reduce the workload, add memory, or live with it. Simple.
> overall execution of the small module functionality may be longer, but
that
> implies that the large piece of code is doing more (otherwise, why is it
so
> large?), so the comparison is between apples and oranges
That also seems to presume that all instructions in both modules are always
executed, I think.
> Given identical functionality and identical residence, the smaller the
code
> is, the quicker it will execute. Invariably.
I would say "the fewer the instructions executed the quicker the whole will
execute", but I'm not yet convinced that a small "module" will necessarily
execute faster than a large one!
-Chuck Stevens
|