Category : Dbase (Clipper, FoxBase, etc) Languages Source Code
Archive   : BULLETIN.ZIP
Filename : MEMC50.016

 
Output of file : MEMC50.016 contained in archive : BULLETIN.ZIP

4/15/92 Blink Inc.
Saving memory with Clipper 5.0 and BLINKER

The following suggestions and recommendations are presented for improved
memory usage by applications written in Clipper versions 5.0 / 5.01 and
linked with BLINKER versions 1.5 or later.

1. Switch off INCREMENTAL linking for the final link.
The command BLINKER INCREMENTAL OFF saves memory by removing the
incremental padding and compressing Clipper's symbol table. To save
memory while developing with incremental linking on, see the Blinker
bulletin "link setup for development and production with Clipper 5.01".

Turning off incremental linking also causes all Clipper code, from both
.OBJ files and .LIB files and from inside and outside the BEGIN/ENDAREA,
to be automatically overlaid and passed to Clipper 5.0's dynamic paging
system. This paging system provides extremely fast, memory-efficient
overlaying of Clipper code with automatic use of expanded memory if it
is available. In the rare situation where an application is desired
with no overlays, the command BLINKER CLIPPER PAGE OFF will deactivate
the Dynamic Paging System while incremental linking is off.

2. Consider overlaying only Clipper code.
For applications that contain mostly Clipper code, with only a few small
C and ASM .OBJ files and third party libraries, overlay only the Clipper
code.

After incremental linking is turned off, this will reduce memory usage
by eliminating the Blinker overlay pool. If Blinker continues to
display the message about the OPSIZE values, there is still some
non-Clipper code that should be removed from the BEGIN/ENDAREA. This
can be done by turning off incremental linking, removing the
BEGIN/ENDAREA statements, and not using any partial link scripts that
contain overlays (ex: CL501MIN.LNK overlays EXTEND.LIB). See example 1
at the end of this bulletin.

3. Overlay as much as possible.
When the combined size of the non-Clipper overlayable modules exceeds
the Blinker overlay pool size, memory can be saved by overlaying as
much as possible and reducing the OPSIZE. See example 2 at the end of
this bulletin.

3-A. Overlay all possible OBJs.
One of the main advantages of Blinker is its ability to dynamically
overlay an extensive range of code. All Clipper .OBJ files, most C, and
many ASM .OBJ files are overlayable.

The first .OBJ file encountered in the link script must be a Clipper
.OBJ file, but this file may now be placed inside the BEGIN/ENDAREA
along with all the other overlays. Only when non-Clipper code is
overlaid, is a fixed area of memory allocated at application start up
for Blinker's overlay pool.

3-B. Overlay all possible libraries.

Overlay all libraries that are composed of Clipper compiled modules,
overlay EXTEND.LIB, and overlay the appropriate portion of the third
party libraries as indicated in our '3RDPARTY' file.

3-C. Beware of inappropriate overlays.

Overlaying OBJ files or libraries that should not be overlaid can cause
an "out of memory" condition or memory corruption. Some third party
libraries are completely overlayable, some supply their own partial .LNK
files, and others have a separate root .OBJ or library. A few of these
root libraries, such as FUNBLINK, need to be SEARCHed. Please review
each third party's documentation for the proper overlay procedures.

3-D. Reduce the OPSIZE.

The memory used by Blinker for its overlay pool is 40K by default. At
link time, Blinker displays the minimum possible memory for the overlay
pool. Using the command BLINKER OVERLAY OPSIZE, this value may be set
as low as the minimum. This will reduce the application memory
requirements at the expense of runtime speed. Any setting below the
minimum will revert to the minimum value (See the Overlay sections in
chapters 3 and 6 of the 2.0 Blinker manual).

3-E. Enable the use of the EMS Pageframe or UMBs for overlays.

Use the commands BLINKER OVERLAY PAGEFRAME ON and BLINKER OVERLAY UMB ON
to move the Blinker overlay pool out of conventional memory into high
memory. To use a UMB, there must be a UMB at least as large as the
opsize. When the overlay pool is placed in the pageframe, the overlay
pool size will be expanded or contracted to the size of the pageframe,
64Kb.

3-F. Overlay portions of CLIPPER.LIB.

The partial link scripts, CL501MID.LNK & CL501MAX.LNK have been provided
to facilitate the overlaying of selected modules from CLIPPER.LIB.
Since use of these will slow down the execution speed of an application,
they should be used only when needed and should be used only when needed
and should be tailored for each application. Systematically comment-out
some of the MODULE commands to identify those modules that should remain
in the root for improved execution speed. The file, CL501STD.LNK, on
our BBS provides a better execution speed for most applications.

4. Use the Blinker memory swapping function.

Consider using the swap function for isolated sections of the
application that could be removed from the main .EXE and executed as
separate .EXE files. By selecting those routines that contribute to the
resident (root) portion of the .EXE, this would free up memory in the
main .EXE and still retain the integrated application, even with
multiple .EXE files. Also if you are running out of memory while using
the Clipper RUN command, switch to the Blinker swap function.

5. Burn the CLIPPER environment variable into the .EXE file.

Use the command BLINKER EXECUTABLE CLIPPER to burn in values for
Clipper's environment variable parameters such as 'E', 'F', SWAPPATH,
SWAPK, etc.

'F' should be set to an odd value to avoid a bug in some versions of PC
DOS 3.3, and 'E' should not be set to 0. In some low memory conditions,
reducing the amount of EMS made available to Clipper through the 'E'
variable can reduce the overhead in conventional memory required to
manage the EMS. Please see the Clipper 5.01 documentation for details
on these parameters.

6. A few Clipper 5.0 coding suggestions.

A. Remove line numbers by using the compile option '/L'.
B. Omit the compile option '/B' to omit debugging information.
C. The symbol table size can be reduced by:
1. converting private variables to static and local
2. reusing variables names
3. using arrays and giving the elements individual names with
the preprocessor.

EXAMPLE 1: Only Clipper code overlaid.

BLINKER INCREMENTAL OFF
BLINKER EXECUTABLE CLIPPER F:
FILE mainprg
FILE prg2
FILE asmprg # small ASM program
LIB GrumpFish # mostly Clipper compiled
( LIB EXTEND # can be omitted )
( LIB CLIPPER # can be omitted )


EXAMPLE 2: As much as possible overlaid.

BLINKER INCREMENTAL OFF
BLINKER EXECUTABLE CLIPPER F:
BLINKER OVERLAY OPSIZE 35
BLINKER OVERLAY PAGEFRAME ON
BLINKER OVERLAY UMB ON # the default
BLINKER PROCEDURE DEPTH 50
SEARCH FunBlink # root library for Funcky 1.52
BEGINAREA
FILE mainprg
FILE prg2
FILE asmprg # small ASM program
LIB GrumpFish # mostly Clipper-compiled
LIB Funcky50
LIB Funcky15
LIB Overcl # Overlay() library
ENDAREA
FILE Resident # root file for Overlay()
@CL501MAX # overlay EXTEND & portions of CLIPPER

DATE 4/15/92 MEMC50
----------------------------------------------------------------
Copyright Blink, Inc. May not be reproduced without permission.
----------------------------------------------------------------