Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jarthur!ucivax!orion.oac.uci.edu!ucsd!hub.ucsb.edu!ucsbuxa!6600m00n
From: 6600m00n@ucsbuxa.ucsb.edu (Steelworker)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Working with TC overlays
Message-ID: <10343@hub.ucsb.edu>
Date: 5 Apr 91 22:12:30 GMT
References: <WIZARD.91Apr4183858@greylady.uoregon.edu>
Sender: news@hub.ucsb.edu
Distribution: comp
Lines: 37

wizard@greylady.uoregon.edu writes:

|I have a really large unix application and have been working to get it to
|compile in the msdos world using Turbo C++ and vroom.

|I have messed around with the overlay buffer size and other tuning stuff
|and still end up with a very slow application.  It just grinds on the 
|disk, interestingly enough if I put the whole thing in a ram drive it
|still is just as slow.   Thus it isn't the speed of the disk, but the
|overlay management itself.

|Anyone know the best approach to the vroom overlay management in terms
|of the number of overlays vs. overlay size.  Is it better to have
|60 or 70 large overlays or hundreds of smaller ones.  What about the
|size of the overlay buffer vs the size of the largest overlay.  Any
|tuning tips would be welcome.
|Thanks
|-Kevin
|wizard@greylady.uoregon.edu
|kevins@ori.org
|kevins@ori.bitnet

The first helpful tool to use is the profiler.  You can set it
up to moniter the overlay calls.  Then, you can decide what items should
not be overlain at all, what should, and that sort of thing. I did this
on a program, and found it was constantly swapping to disk when the
mouse was in a region, which snailed the program.  I unoverlaied it,
and the program sped up.  Also, try to group functions so there
is not alot of cross calling between modules.

Once you get the profiling set up, you can set your overlay buffer 
so things work well.  Also, you can instruct the program to swap 
overlays to EMS or extended memory. 
Good luck,
Rob
6600m00n@ucsbuxa.ucsb.edu
	|| ucsbuxa.bitnet