lim@iris.ucdavis.edu (Lloyd Lim) (11/03/89)
Excuse me if this has been discussed before, I just noticed it recently. I'm
working on an application that is computation-intensive and I've noticed that
when I build the application it runs about 15% faster than the project. What
differences cause this? There is any serious memory movement taking place
but I do make a few printf calls for debugging. Does the ANSI library speed
up for some reason? Unlikely, but I don't have a clue.
+++
Lloyd Lim Internet: lim@iris.ucdavis.edu (128.120.57.20)
Compuserve: 72647,660
US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616oster@dewey.soe.berkeley.edu (David Phillip Oster) (11/05/89)
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. LightSpeed Pascal code was full of no-ops, to leave hooks for the debugger. THINK C doesn't work that way.
sho@maxwell.physics.purdue.edu (Sho Kuwamoto) (11/06/89)
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.
lippin@twinkies.berkeley.edu (The Apathist) (11/06/89)
Perhaps you are running with the LSC debugger? It has been my experience that the debugger always uses a sleeptime of 0, and is quite the CPU hog when MultiFinder lets it in. So your calls to WaitNextEvent, GetNextEvent, and EventAvail will take many times longer. --Tom Lippincott lippin@math.berkeley.edu "The train is the same; only the time is different. Ecce homo, ergo elk."
siegel@endor.harvard.edu (Rich Siegel) (11/06/89)
In article <32366@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >LightSpeed Pascal code was full of no-ops, to leave hooks for the >debugger. THINK C doesn't work that way. Um, no. Lightspeed Pascal version 1 procedures would sometimes have a NOP at the beginning and the end of a procedure, if the code generator discovered that there were no locals, no arguments, and no compiler temps. In such cases, the code generator would go back and replace the LINK A6, #n with a NOP, and replace the UNLK A6 with a NOP. So at worst case, there would be a pair of NOPs in a procedure or function. Code compiled with Debug on has TRAP instructions in it, but no NOP instructions. Code compiled under version 2 or later (!) has no NOP instructions in it, period. In THINK C, the debug information is separate from the code; this means that there is no special code required for debugging, and therefor no rebuild step for building a non-debug application. On the other hand, the optimizer sometimes gets in the way of debugging (such as making it i impossible to crawl the stack by eliminating LINK/UNLK when appropriate). R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "There is no personal problem which cannot be solved by sufficient application of high explosives." ~~~~~~~~~~~~~~~
eacj@batcomputer.tn.cornell.edu (Julian Vrieslander) (11/06/89)
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. A couple of my projects actually run a few percent faster as projects than as applications. These programs do very little accessing of resources, but are very math-intensive (lotsa FPU calls). Just another precinct reporting.. -- Julian Vrieslander Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853 UUCP: {cmcl2,decvax,rochester,uw-beaver}!cornell!batcomputer!eacj INTERNET: eacj@tcgould.tn.cornell.edu BITNET: eacj@CRNLTHRY