a comparison of the effects of structured vs. non-structured and modularized vs. non-modularized programs on run time (abstract only)  this paper presents the basis for analytical research, examining the various effects of modifying or amending a particular program in both its basic structure and its degree of modularity on its ultimate run time. we begin with a program which produces as output a series of tables of high card and distribution counts of 1000 bridge hands. the deal of each bridge hand is accomplished by a random number generator function and the program employs a test module to ascertain valid results.  the original program is written in turbo pascal with a high degree of modularity. it is later modified by an "unwrapping process" to produce a less modularized program which effects the same results as the original. the comparison of source lines of code, degree of modularity, number of modules, and run time in addition to actual output are noted and analyzed. the programs were executed on an ibm pc.  the original program contains 272 lines of code, six procedures (in addition to the main control module), and has an execution time of approximately 12 minutes. the first of the six procedures is the deal of the cards (which is invoked once per iteration, for a total of 1000 calls). the next three procedures are counting modules (each of which is invoked four times per iteration for a total of 12000 calls). the fifth procedure is a test module which supplies the programmer with a sample hand and counting data for validation purposes (which is invoked once per 100 deals for a total of 10 calls). finally, the sixth procedure is one which computes frequency data (and is invoked a total of 6 times after the 1000 deal iteration has terminated).  the program is highly structured with a complexity measure of 212. due to its high degree of modularity, it can be read and debugged with little or no difficulty.  the less modularized version is acquired by an unwrapping process as follows:  the deal procedure is eliminated and its code is placed directly in the main module;  the three counting modules are no longer invoked as procedures but are instead placed within the main module. since each of these three modules had been called four times per iteration (once per each bridge hand) this results in four times as much code;  the test and frequency modules are left intact.  this version of the program contains 373 lines of code, two procedures (in addition to the main control module), and has an execution time of approximately 13 minutes. the first procedure is the test module (which as before is invoked once per 100 deals for a total of 10 calls). the second procedure is the frequency procedure (invoked six times after the 1000 deal iteration). the main module is now much larger than in the original version, having absorbed four procedures with a high degree of repetition of code.  this program contains a complexity measure of 316. due to its lack of modularity and much higher sloc and complexity measures, its readability and facility for debugging are greatly reduced. it is especially noteworthy that the unwrapped version of the program, although containing 13000 less procedure calls than the original, did not have a shorter run time than the original. a summary of the results:  domenick j. pinto sandra k. honda