Code Comments
Programming Forum and web based access to our favorite programming groups."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
Post Follow-up to this messagePowered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.