Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!agate!athena.berkeley.edu!ucbked
From: ucbked@athena.berkeley.edu (Earl H. Kinmonth)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Code size generated by Turbo C
Message-ID: <1990Sep19.235542.8842@agate.berkeley.edu>
Date: 19 Sep 90 23:55:42 GMT
References: <139400009@uxa.cso.uiuc.edu> <26252@cs.yale.edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: Centre for Japanese Studies, Univ. of Sheffield
Lines: 20

In article <26252@cs.yale.edu> spolsky-joel@cs.yale.edu (Joel Spolsky) writes:
>In article <139400009@uxa.cso.uiuc.edu> klg0582@uxa.cso.uiuc.edu writes:
>>One thing I don't like for Turbo C is that the
>>executable code for the program of same purpose is larger in C than in
>>pascal. Is this generally true or is there a way to avoid this?

Even with all of the debug options turned off, Turbo C produces rather
bloated *.exe files.  The MKS Toolkit includes an analog to **IX strip
that will generally reduce *.exe files by 25-40%.

Essentially this does what one of the options in the MSC linker does,
if I remember correctly.  Assuming (I don't have time to check) the
processing is similar to **IX, tlink is probably leaving the symbol
table attached to the executable, although this has no subsequent use
(except with standalone debuggers).

One should also check for floating point library inclusion.  A single
floating point calculation, especially with emulation, will add
substantial overhead.  Moreover, simple floating point calculations can
often be replaced by integer operations.