Board index » delphi » Overlay Analysis

Overlay Analysis

On 16 Feb 1997 12:57:01 -0700, Mike Copeland <mrc...@primenet.com>
wrote:

Quote
>I want to know the actual size of each overlayed Unit that's packed into the .OVR
>file.   Anyone know how?  TIA

If it helps, I have noticed that when overlays are compiled, it will
only place code into the overlay and not data, meaning if you set up a
simple unit that has a function such as:

procedure writeit;
  begin
     writeln('Hello!');
  end;

it only seems to place code for writeln in the overlay, and places the
constant 'hello!' in the executable itself.  Even more noticable is
ifyou use a unit to define a constant array.  You will notice when you
compile a program that is supposed to overlay this unit only and it
will not bomb when the overlay is not present.
Glenn Grotzinger
Web Page: http://www.geocities.com/Paris/3537
Writer of the Excellent Training Manual known as the TP Tutorial.
To email, if you hit the reply button, delete the {remove_this}
out of the replied message.  Just some protection from SPAM. :(

 

Re:Overlay Analysis


I am (finally) using overlays in several of my larger programs, and I
must say it's a wonderful thing!  However, I can see that use of
overlays can be optimized by making the individual overlayed Units as
nearly equal in size as possible, so the buffer shares as much as
possible with many Units participating in the effort.
   My question is this: is there any tool or technique with which I can
determine the compiled size of each overlay Unit in the collection?  I
see that they all get "packed" into a single .OVR file, but it seems
that the more I can make the components of that .OVR file similar in
size, the better the system will function (assuming I don't create a
thrashing situation, of course).
   I know that I can _manually_ look at the .MAP file and see the
beginning/end addresses of each overlayed Unit, but that seems like a
lot of work for what I want.  I could also write a program which
examines and reposts the .MAP information - also a fair amount of
needless work if there's already some way to get this information.
   BTW, the .MAP header information won't work for me, because each
overlayed Unit reports only about 55 bytes of size - I presume that's
some sort of "stub" information retained in the .EXE which the Overlay
Manager uses, and that's not what I'm looking for at all.  I want to
know the actual size of each overlayed Unit that's packed into the .OVR
file.
   Anyone know how?  TIA

Re:Overlay Analysis


Dear Mike,

On 16 Feb 1997 12:57:01 -0700, Mike Copeland <mrc...@primenet.com> wrote:

Quote
>I am (finally) using overlays in several of my larger programs, and I
>must say it's a wonderful thing!  However, I can see that use of
>overlays can be optimized by making the individual overlayed Units as
>nearly equal in size as possible, so the buffer shares as much as
>possible with many Units participating in the effort.

I'm not sure what gave you the idea that unit of equal size will perform better.
I, personally, don't see any reason why this should be the case. Moreover, it's
quite a waste of effort to try and make each unit as big as the other. I've
worked quite a bit with overlayers and it is my experience that you should try
to avoid program loops that need so many overlayed unit that they cannot all be
fitted into the overlay buffer at any one time anymore. Of course we all want to
keep the overlay buffer as small as possible. This almost automatically implies
that our most intensively used units should be small rather than big. SMALL, but
not necessary of EQUAL SIZE.
It would be very helpful to determine when, and how many time, a unit was loaded
into the overlay buffer. To do this you can redefine the OvrReadBuf function of
the Overlay unit. Here's the new definition:

VAR
  OldOvrReadBuf:OvrReadFunc;

FUNCTION NewOvrReadBuf(OvrSeg:WORD):INTEGER; FAR;
{redefinition}
BEGIN
{log}
  WriteLn(OvrLogFile,LONGINT(OvrSeg-PrefixSeg-16) SHL 4);
{call old}
  NewOvrReadBuf := OldOvrReadBuf(OvrSeg);
END; {NewOvrReadBuf}

And here's the way to incorporate it into your program. You should do this right
after you initialized and resized the overlay buffer, but before it is being
used.

  OldOvrReadBuf := OvrReadBuf;
  OvrReadBuf    := NewOvrReadBuf;
  Assign(OvrLogFile,'OVRCALLS.TXT');
  Rewrite(OvrLogFile);
  WriteLn(OvrLogFile,Name);

Don't forget to close the file when the program ends. This little bit of code
will give you a complete listing of all the loads into the overlay buffer. I've
made a tiny utility that can use this file, and the map file, to tell you how
many times a certain unit was (re)loaded. In the end it is this reloading of
units that will slow down an overlayed program. If you want the utility I can
e-mail it to you. Just e-mail me.

Peter de Jong
wpdej...@worldonline.nl

Re:Overlay Analysis


Quote
Mike Copeland wrote:

>    My question is this: is there any tool or technique with which I can
> determine the compiled size of each overlay Unit in the collection?

Hi Mike,

After compiling each unit seperately, check "Code size" in the Compile/Information
dialog.

I hope this helps,

Votis Kokavessis

Re:Overlay Analysis


Quote
Mike Copeland wrote:

>    My question is this: is there any tool or technique with which I can
> determine the compiled size of each overlay Unit in the collection?

Hi Mike,

After compiling each unit seperately, check "Code size" in the Compile/Information
dialog.

I hope this helps,

Votis Kokavessis

Re:Overlay Analysis


On 16 Feb 1997 12:57:01 -0700,  Mike Copeland <mrc...@primenet.com> wrote:

Quote
>   My question is this: is there any tool or technique with which I can
>determine the compiled size of each overlay Unit in the collection?  

Hello Mike,

Occasionally I take a snapshot of the map file.  As you've found, an overlaid
unit only lists the size of the non-overlaid stub.  So I begin by disabling the
list of overlaid units by using the alternate comment or a compiler directive.
I then enable Options|Linker|Map file segments and compile the program.  I use
to manually extract names and size information from the map file, and sort this
by unit name.  This became old fast, so I wrote a quick-n-dirty utility to do
the grunt work for me. The program builds a sorted list of unit names and sizes
that is suitable for including in the program.  

I use an editor that can manipulate columnar data to paste this information into
the program so that I can retain comments.  After updating the program file, and
selecting those units that I want to be overlaid, I re-enable overlays and
recompile the program and again take a snap shot and include the size
information.  The result is a section in the program that looks like:

{$IFNDEF DPMI}
    { ------------------------------------------------------------- }
    { ALL UNITS ARE LISTED IN ALPHABETICAL ORDER REGARDLESS IF THEY }
    { CAN BE OVERLAYED OR NOT.  THIS FACILITATES TAKING INVENTORY   }
    { USING THE IDE's UNIT BROWSER, or sorted SEGMENT.MAP File      }
    { ------------------------------------------------------------- }
    { Snapshot taken 950106 ..red }
        {   Name       } { normal    overlay }
        {$O ABOUT      } {   1635 } {     42 } { 1-2 k saved w/ overlay  }
        {$O APP        } {   5746 } {    227 }
        {-O APPCONST   } {      0 } {      0 } { size too small          }
        {-O APPDEF     } {    439 } {    439 } { < ? k saved w/ overlay  }
        {$O APPDESK    } {   1779 } {     72 } { 1-2 k saved w/ overlay  }
        {-O APPHELP    } {      0 } {      0 } { size too small          }
        {-- APPOVR     } {    523 } {    523 } { --cannot be overlayed-- }
        {$O APPUTIL    } {   1414 } {     57 } { 1-2 k saved w/ overlay  }
        {$O BITSET     } {   1022 } {     92 } { 1-2 k saved w/ overlay  }
        {$O BLOCKIO    } {   3784 } {    142 }

You can have a copy of the map utility if you want.  The file it creates is the
first two columns of the above, as "{-O UNITNAME } { DecimalSize }"

If you're interested, you can also have a copy of APPOVR which looks in the
programs directory for an appropriate .OVR, and if not found, tries the .EXE.
This makes it work for separate .OVR during development and a production version
which has the overlay file appended to the .EXE.  It does a few other things
like determine an optimal buffer size and moving overlay to EMS.

    ...red

Re:Overlay Analysis


On 16 Feb 1997 12:57:01 -0700,
Mike Copeland   <mrc...@primenet.com> wrote:

  I want to

Quote
>know the actual size of each overlayed Unit that's packed into the .OVR
>file.
>   Anyone know how?  TIA

Here's a program that prints out the size of each unit's code and data:

{$I-}
program GetUnitInfo;

uses
                    DOS;

const
                Prefix = '..\BIN\'; w = 10;

type
                  frec = record
                           fill: array [ 1..34 ] of char;
                           codelen, cons: word;
                           fillx, fillxx2: integer;
                           data: word;
                         end;

                    fr = file of frec;

var
                      f: fr;
                      s,
                     fn: string;
                    rec: frec;
                DirInfo: SearchRec;
                totC, totv: longint;

begin { readdata}
   fn := paramstr( 1 );
   totv := 0; totc := 0;
   writeln(' ':18, 'Code':w, 'Consts':w, 'data':w, 'consts+data':w );
   FindFirst( Prefix + '*.TPU', AnyFile, DirInfo );
   while DirInfo.SearchError = 0 do
      begin
         s := Prefix + DirInfo.Name;
         assign( f, s );
         reset( f );
         if ioresult <> 0
         then
            writeln( s, ' not found.' )
         else
            begin
               read( f, rec );
               with rec do
               begin
                  close(f);
                  totv := totv + data; totc := totc + cons;
                  writeln( s: 28, codelen:w,
                           cons:w, data: w,
                           cons+data:w );
               end;
            end;
         FindNext( DirInfo );
      end;
      writeln('total consts: ', totc:10, '   total data: ', totv:10 );
end.

-----------------------------------------------------------------------
George R. Gonzalez                        g...@boombox.micro.umn.edu
Sr. Sys. Programmer                       University of Minnesota

Re:Overlay Analysis


Quote
Mike Copeland wrote:
>    My question is this: is there any tool or technique with which I can
> determine the compiled size of each overlay Unit in the collection?

Have you tried analysing the contents of the overlays' stubs? I seem to
recall that this information is stored there- it must be stored
somewhere,
after all, so that the overlay manager knows how much memory to slide
around. I think you'll find that each overlay carries a relocation table
around with it as well: the size of this animal is also stored in the
stub.

Chris.

Re:Overlay Analysis


Re: Overlay Analysis

MR> Manager uses, and that's not what I'm looking for at all.  I want
MR> to know the actual size of each overlayed Unit that's packed into
MR> the .OVR file.

Ive always just guesstimated by the size of the .TPU that will be
overlaid and loaded them all into XMS and forgot about it :)

  22   Homer's Hut        Topeka, KS     (913)235-3899    VA 2.0   22
    22     VirtualNet 1913001          FidoNet 1:299/120     22

Other Threads