Path: utzoo!attcan!uunet!wuarchive!mailrus!iuvax!purdue!mentor.cc.purdue.edu!pur-ee!pur-phy!maxwell.physics.purdue.edu!sho
From: sho@maxwell.physics.purdue.edu (Sho Kuwamoto)
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK C build speed-up
Message-ID: <2727@pur-phy>
Date: 5 Nov 89 19:07:56 GMT
References: <5804@ucdavis.ucdavis.edu> <32366@ucbvax.BERKELEY.EDU>
Sender: news@pur-phy
Reply-To: sho@maxwell.physics.purdue.edu.UUCP (Sho Kuwamoto)
Organization: Purdue Univ. Physics Dept., W. Lafayette, IN
Lines: 18

In article <32366@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>I would expect an application built from THINK C to be slightly faster
>than running the project, because any GetResource() of code will have to
>search the resource map of the ".rsrc" file, fail to find it there, and
>have to go to the resource map of the ".proj" file to find the resource.
>As an application, it would find it in its own resource file. A little
>faster.  

I doubt this is the problem.  For normal resources, it would take about
the same time, for CODE resources, it would be slower.  I'll bet you
a bowl of fingernails that this speed problem occurs even if there
are no calls to UnloadSeg() at all.  I seem to remember something about
doing limited optimization (jumps maybe?) when the application was
built.  Rich?

-Sho
--
sho@physics.purdue.edu  <<-- limited.