wizard@greylady.uoregon.edu (KevinS) (04/05/91)
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
--
--------------------------------------------------------------------------
Kevin D Smolkowski. J.D.
Also available at a machine near you!
Kevins@ori.org Kevins@cie.uoregon.edu wizard@chemstor.uoregon.edu
"A conclusion is the place where you got tired of thinking."
--------------------------------------------------------------------------6600m00n@ucsbuxa.ucsb.edu (Steelworker) (04/06/91)
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
wizard@greylady.uoregon.edu (KevinS) (04/06/91)
In article <10343@hub.ucsb.edu> 6600m00n@ucsbuxa.ucsb.edu (Steelworker) comments on my article: |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 I have moved things around so that there is not a lot of cross calling between modules, which helped some. As far as profiling goes, the linker just locks up without a message when I try and use the debugging information. The exe without debugging is about 900k. -Kevins wizard@greylady.uoregon.edu -- -------------------------------------------------------------------------- Kevin D Smolkowski. J.D. Also available at a machine near you! Kevins@ori.org Kevins@cie.uoregon.edu wizard@chemstor.uoregon.edu "A conclusion is the place where you got tired of thinking." --------------------------------------------------------------------------