Path: utzoo!attcan!uunet!lll-winken!sun-barr!cs.utexas.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!hpda!hpwala!hpavla!griffith
From: griffith@hpavla.AVO.HP.COM (Jeff Griffith)
Newsgroups: comp.windows.ms
Subject: Re: Pleasures and Penanties of the Large Model
Message-ID: <16980007@hpavla.AVO.HP.COM>
Date: 12 Sep 90 18:35:47 GMT
References: <82934@aerospace.AERO.ORG>
Organization: Hewlett-Packard Avondale Division
Lines: 37

I'm really surprised and dismayed that Microsoft has forced the near/far
pointer issue into the design of code.

Between '84 and '86, and for the last two years I've had to put up with 
worrying about whether I'm using far pointers or near pointers, the size
differences, whether or not a given module can access a piece of data,
changes in user interface specifications that force more and more data
to be accessed with far pointers or increase the size of modules because
everyone wants access to all data from everyplace, all of the time, etc.

The most pleasant experience I've had as a software engineer was to use
only large model (between '86 and '89). I found that the time I spent
worrying about pointer problems could be used to refine the data accessign
algorithms to the point where all performance penalties were hidden behind
the ~2 second repaint time of the application. I should tell you that these
were data analysis programs, using up to 6 processes to handle between 4 Meg
and 10 Meg of data, running under Xenix 3.3 to 3.5 on Intel 286 based
multiuser systems, and writting on VT-220 terminals. Most of the performance
was gained but using multiple processes to handle the various data flows;
in all cases, I was able to divide the program into various event handlers,
and each handler had a "block" point so that, in most cases, only one process
was running at any given time; the few cases of overlap occurred when the user
was walking through the menu and the program was reading data. The data stream
could have been held off. Otherwise, the use of multiple process simplified 
the coding by isolating the data. Such a system could be more easily built
using a single process and C++.

Additionally, I was able to respond to changes in customer requirements more
rapidly, program debugging time was reduced (which gave me even more time to
spend with customers), and program reliability improved.

Whatever speed you gain (less than 25%) by changing memory model, you can
also gain by improved program design. If you really need speed after you've
got a clean design, you can take the ".s" file produced by the compiler
and use it as the basis for writing assembly code; you can probably get
another 50% that way. But don't try to use the near/far pointer argument
for hiding a poor design; if you want speed, you have to design for it.