BLINKER MEMORY PACK     (Clipper Summer '87)
------------------------------------------------------------------------------

  Purpose : Specify automatic memory packing frequency

  Syntax  : BLINKER MEMORY PACK <nuFrequency)

  Default : 0

  Example : # Set the packing to once every 20 overlaid procedure calls

            BLINKER MEMORY PACK 20

  This command is used to set the frequency with which the Blinker overlay
  manager defragments Clipper free memory. The parameter is a decimal
  number indicating the number of overlaid procedure calls after which
  memory is defragmented, and may be set to any value from 0 to 65534.
  (The default value is 0, which causes no packing to occur.)

  Clipper is continually allocating and freeing dynamic memory, causing it
  to become more and more fragmented as execution of an application
  continues.  Clipper only considers memory to be available if it is in
  chunks of 4kb or greater, thus large applications can often run out of
  memory after prolonged execution.

  The BLINKER MEMORY PACK command allows the developer of a Clipper Summer
  '87 application to defragment dynamic memory as often as needed without
  modifying the application, and to tune the frequency of the packing to
  suit the individual application. This process is also performed by the
  Clipper function MEMORY(0), but much more slowly.

  The defragmentation process consists of two things: joining up of
  contiguous blocks of free memory, and then resetting the roving pointer
  which is used in selecting (indicating) the next memory allocation.  At
  the time of the defragmentation, this pointer is set to specify the
  highest available location in memory. This causes memory to be allocated
  from the beginning each time rather than fragmenting the whole memory
  area, which can significantly reduce the deterioration of available
  memory due to fragmentation.

  Due to the underlying architecture of Clipper Summer '87's memory
  allocation scheme, it is not possible to move allocated blocks of memory
  around, as there is no means of updating the pointer(s) to allocated
  blocks. This means that true garbage collection is impossible, but the
  defragmentation described here is the next best thing, and helps the
  problem considerably.

  Setting the frequency to a low number may slow down the application, but
  will keep memory fragmentation to a minimum, giving the maximum saving
  on memory.  Setting the frequency to a higher number will not noticeably
  slow the application down, but the memory gain will be less as the
  fragmentation will be relatively worse (although still a lot better than
  with no packing at all.)

  An optimum frequency appears to be around 10 for an average application,
  giving a significant increase in memory while not significantly slowing
  the application.  The optimum frequency for a given application may vary
  considerably from this frequency, and can only be established by trial
  and error.