Path: utzoo!attcan!uunet!microsoft!kensy
From: kensy@microsoft.UUCP (Ken SYKES)
Newsgroups: comp.windows.ms
Subject: Re: Pleasures and Penanties of the Large Model
Message-ID: <57452@microsoft.UUCP>
Date: 16 Sep 90 00:00:51 GMT
References: <82934@aerospace.AERO.ORG> <16980007@hpavla.AVO.HP.COM>
Reply-To: kensy@microsoft.UUCP (Ken SYKES)
Organization: Microsoft Corp., Redmond WA
Lines: 22

In article <16980007@hpavla.AVO.HP.COM> griffith@hpavla.AVO.HP.COM (Jeff Griffith) writes:
>I'm really surprised and dismayed that Microsoft has forced the near/far
>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.

PLEASE don't edit assembler code generated by the compiler.  This violates
some of the very same rules the rest of your message points out: Writing 
code that is algorithmically efficient and maintainable.  Editing compiled
code blows maintainability right out the door.  Are you going to throw
away the original C code and stick with the assembler, or are you going to
"optimize" every time the C code needs to change?  This is bad news.
Instead of doing that find some other way to optimize the code at the C
level.  Maybe use a few NEAR pointers where necessary.  Yes I know you
hate them but they perform some of the operations that your asm code tweaks
would and its much easier to maintain.  

Ken Sykes
Disclaimer: The above opinions are solely my own.