home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!rpi!uwm.edu!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
- From: tdarcos@mcimail.com (Paul Robinson)
- Newsgroups: comp.compilers
- Subject: [TDR] Fat Code
- Keywords: optimize, design
- Message-ID: <93-01-043@comp.compilers>
- Date: 8 Jan 93 02:51:12 GMT
- Article-I.D.: comp.93-01-043
- Sender: compilers-sender@iecc.cambridge.ma.us
- Reply-To: Paul Robinson <tdarcos@mcimail.com>
- Organization: Compilers Central
- Lines: 76
- Approved: compilers@iecc.cambridge.ma.us
-
- "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
- --
- Send compilers articles to compilers@iecc.cambridge.ma.us or
- {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
-