Overlays save memory but slow down execution

Havik

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Overlays save memory but slow down execution

I wrote a program in TP7 that uses about 50 units all declared as overlay
in order to avoid an out-of-memory error. (The EXE-file plus OVR-file is
about 400kB.)
When I run this program, some procedures are far too slow. When I embed one
such procedure (just for testing) in a new program, leaving out irrelevant
things and all overlay declarations, it is about 10 times faster. (The
resulting executable is about 200kB).
Is this deceleration a known property of overlays and...
can it be cured?

--
Havik
ha...@qconcepts.nl (remove spam preventing q)

Pedt Scrag

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Re:Overlays save memory but slow down execution

Havik mailto:ha...@qconcepts.nl said:

Quote

>I wrote a program in TP7 that uses about 50 units all declared as overlay
>in order to avoid an out-of-memory error. (The EXE-file plus OVR-file is
>about 400kB.)
>When I run this program, some procedures are far too slow.

Do your overlaid units call each other and that you have an overlay
buffer set to the default of the biggest unit and do you not bother
trying to copy the overlay to EMS ?

Any will slow your program down and the more combinations that you can
say 'yes' to will slow your program down even further.

--
Did they *really* mean to call the cut down Windows version 'winCE' ?

Mike Copela

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Re:Overlays save memory but slow down execution

Quote

> I wrote a program in TP7 that uses about 50 units all declared as overlay
> in order to avoid an out-of-memory error. (The EXE-file plus OVR-file is
> about 400kB.)
> When I run this program, some procedures are far too slow. When I embed one
> such procedure (just for testing) in a new program, leaving out irrelevant
> things and all overlay declarations, it is about 10 times faster. (The
> resulting executable is about 200kB).
> Is this deceleration a known property of overlays and...
> can it be cured?

Yes, this effect is entirely possible - if you don't carefully analyze
and restructure your code to make overlays for _for_ you. As Pedt has
suggested, simply slapping the "overlay" template around all your Unit
sources and expecting any kind of reasonable execution performance is
naive...and dumb. You have to package your overlayed Units in a manner
which follows the logical calls/uses within the program (all initialize
code logic in one overlay; termination/windup logic in another; discrete
menu functions in separate overlays; etc.). This isn't a simple or easy
thing to do, and it requires great understanding of how the program
executes, what it does at each "function", all the while thinking "What
needs to be in memory while this executes?"
Note that certain global functions/procedures shouldn't be overlayed,
particularly when 2 or more logical functions use them. Doing so will
cause "overlay thrashing" (the situation you're experiencing, I'm sure),
as each overlay has to swap out to load another so that the common
subprogram can execute...followed by it swapping out so the caller
overlay can come back in to execute. Thus, common subprograms should be
kept in a Unit which _isn't_ overlayed, so that they stay in program
memory and can be accessed by all overlays.
Implementing overlays in a program is often a tedious "learning
experience", as one develops an understanding of what can be separated
into overlay Units, what cannot, and how to structure his/her program
logic to assure each overlay can do its own work without swapping in/out
for another. Another thing to watch for is the _size_ of each overlay,
since TP will use a fixed overlay buffer of at least the size of the
largest overlay Unit - so it's best to keep the code of each overlayed
Unit about the same as all others, if possible (quite hard to do,
too...).
Good luck...

Pedt Scrag

Delphi Developer

Wed, 18 Jun 1902 08:00:00 GMT

Re:Overlays save memory but slow down execution

Mike Copeland mailto:mrc...@primenet.com said:

Quote

>> I wrote a program in TP7 that uses about 50 units all declared as overlay
>> in order to avoid an out-of-memory error. (The EXE-file plus OVR-file is
>> about 400kB.)
>> When I run this program, some procedures are far too slow. When I embed one
>> such procedure (just for testing) in a new program, leaving out irrelevant
>> things and all overlay declarations, it is about 10 times faster. (The
>> resulting executable is about 200kB).

> Yes, this effect is entirely possible - if you don't carefully analyze
>and restructure your code to make overlays for _for_ you. As Pedt has
>suggested, simply slapping the "overlay" template around all your Unit
>sources and expecting any kind of reasonable execution performance is
>naive...and dumb.

One thing I forgot to mention, I've a program available via
http://www.pedt.demon.co.uk/usenet/ that will give you the
size of each unit code within the overlay which might help.

There's also a unit that will allow the load the overlay file
into XMS memory - which memory I suspect people are more likely
to have than EMS.

--
Did they *really* mean to call the cut down Windows version 'winCE' ?

Other Threads

1. Threaded SQL execution slows down DBGrid?

2. Virus Checking slow down Program Execution

3. repeating INSERT / DELETE cycle -> slow execution down

4. Memory builds up, app slows down

5. Allocated memory builds up, app slows down

6. Slowing down of the system and huge use of memory

7. Slowing down the down key repeat in DBGrid

8. D2, Overlays and Memory

9. Slow Query Execution

10. stored procedure execution is so slow