[TDR] Fat Code

"Fat Code" is where an application is overly bloated, either because the
compiler is inefficient (more about reasons you might want that in
"Compile Time vs. Run Time"), because the programmer has chosen a bad
implementation of a particular means to perform an algorithm, or because
the programmer has coded something using a standard method which is in and
of itself a heavy user of resources. Let me look at all of these.


When compilers first came out, the compiler writers were, in almost all
cases, employees of the hardware manufacturer. Since they could get
access to the designers of the hardware, they could find out how to do
things in ways which are much more efficient than the average user.


For example, in certain cases, a shift is more economical than a multiply
by two. But not if the user wants the overflow condition that a multiply
might generate and a shift might not, or vice versa, or that one would
generate one class of condition and the other wouldn't.


Now, compilers are written by employees of companies that in some cases do
nothing but sell compilers. Therefore their interest is in pushing
product, not in the tweaking for performance that in some cases can help.
On the other hand, there can be enough of a market for certain kinds of
compilers as to be worth it to implement some of them to be more efficient
in certain operations.


Coder bloat in "fat code" occurs when the user writes an algorithm using a
real resource hog of an application with no attempt to do it differently,
or maybe the person is not-well trained enough that they don't know any
other way to do this. One example would be doing a bubble sort on a large
number of elements, but because this is a dog on performance, reading the
entire database - say 100,000 records - into memory. This isn't a good
example because most large computers, COBOL compilers and even MS-DOS and
DBASE have built in sort routines, but you get the idea.


Algorithm bloat is somewhat related to Coder Bloat, but it is much more
subtle. Perhaps one case would be use of a standard sort routine supplied
with an application that is only 1/10 as efficient as a different method.
I know there is a difference but I can't quantify it as yet.


Then there is the bloat caused simply by USING a high-level language.
For example - and this seemed to be a universal constant - any FORTRAN
program, even one consisting of one CALL EXIT statment, would use 18
blocks of disk space on a PDP-11 (one block is equivalent to 512 words),
and it would take 18 pages on a UNIVAC VS/9 mainframe (this is equivalent
to an IBM 360 or 370 (now called the 3090)). Both use 18 units of disk
space as a minimum.


If you programmed in Basic, if you used an interpreter, a great deal of
the code is used for safety checks, i.e. range checks, INPUT statement
limits, and on multi-user systems, privelege checks. All of this uses
space and makes the interpreter larger. If your program could be
compiled, a lot of the run-time library (that often was never used) was to
check for things.


Now we have "smart linkers" that can decide not to include part of the
Run-Time library if you don't use it. Funny but we had the same thing on
mainframes in 1978, it simply placed routines by name and if they weren't
called, they weren't included.


Now we have MS-Windows. This brings new meaning to the term "Resource
Hog." Like calling Niagra Falls "moist." One person referred to MS
Windows as being "4 Meg of memory to play Solitaire."


There is an important point to make about fat code, and not just in
respect to something like Microsoft Windows; if a program is small it will
run in a smaller space. And it will probably run faster.


I once pointed out something important to someone about a good reason to
develop code that is usable on an 8086. Because if it runs at a
reasonable speed on a 4 MHZ 8086, run it on an 80486 and it will run like
a "bat out of hell." Even with all the overhead of MS Windoze, it will
still give MUCH better performance.
---
Paul Robinson -- TDARCOS@MCIMAIL.COM
--

Return to the comp.compilers page.
Search the comp.compilers archives again.