This article is reprinted from the October 1990 edition of
TechNotes/dBASE IV.  Due to the limitations of this media, certain
graphic elements such as screen shots, illustrations and some tables
have been omitted.  Where possible, reference to such items has been
deleted.  As a result, continuity may be compromised.  

TechNotes is a monthly publication from the Ashton-Tate Software
Support C*enter.  For subscription information, call 800-545-9364.

A Memory Primer
Joe Stolz

Now that version 1.1 is out, many users may be mystified by the number
of ways that memory can be fine-tuned in dBASE IV.  I have to admit,
it's not at all obvious in what manner these new features can be
applied to your benefit.   

In an effort to introduce the new memory tweaking features and to give
some tips to use them at their best advantage, I've composed this
article.  In it, I endeavor to define Dbcache, Dbtmp and Dbheap, the
Three Musketeers of Memory Management, in a clear and lucid fashion,
complete with the most basic tips as to the tuning of these features
to your own best advantage.  

Dbcache

dBASE IV now can be installed with a disk caching utility called
Dbcache.  This cache, once installed, is loaded and removed from
memory easily, with only the slightest hint of its working; there is a
sign-on and sign-off screen that flashes by while dBASE IV is loading
or quitting.  You may be asking what is the cache, when do you use it
and why? 

The cache is a special tool that works in Expanded or Extended memory,
speeding the access to the hard disk of your computer.  No matter how
fast your hard disk is, your computer's memory is faster. 
Consequently, if you have the extra memory in the computer, it should
be used to your advantage.  The cache sits in that memory above 640K
and allows dBASE IV to access information such as your data or dBASE
system files much more quickly.   

A major caveat to this whole process: if you don't have Extended or
Expanded memory in your computer, you will be unable to use Dbcache. 
If your computer has only 640K in it, caching is not in your future
(unless the purchase of an EMS board is).   

Which raises a question: why doesn't the cache work in the main 640K
of memory that dBASE IV isn't  using?  If dBASE IV only requires 450K
of memory to run, can't the cache snug right in above dBASE IV and
make it all work faster and better?  Well that's not exactly the way
it works.  First off, there isn't a great deal of memory free above
the area that dBASE IV occupies within the 640K limit.  If the cache
were to be placed there, it would have to be a pretty tiny cache, too
small to help very much.  It turns out that the minimum size of an
effective cache is about 500K.  A 1 megabyte sized cache is even
better.  So if your computer has 1 megabyte on the mother board, you
have only 384K free of memory that can be used for a cache.  That's a
bit small in the world of cache buffers.   

Another fact of life is that the cache must occupy a finite amount of
real (640K) memory.  In the case of Dbcache, that is 25 to 30K of
memory which is, again, memory above where dBASE IV is loaded.  If you
have a single user system, 30K is a small price to pay for an
extremely fast cache.  However, if your computer is a workstation on a
local area network where a network shell is loaded into memory, losing
another 30K of precious main memory is questionable indeed.  On some
networks, you may not have the memory available.  If you do have the
space, is it worth the 30K loss?   

What if you don't use a network, but rather, you keep a number of TSR
(terminate and stay resident) utilities such as Sidekick or Metro
claiming precious real estate in your base memory?  Is that going to
effect the use of the cache?  The answer to both the network situation
and the TSR question is not exactly clear cut.  Let's examine an
important fact about your 640K and perhaps we can point to the best
course of action in these circumstances.  No matter what the memory
configuration of your computer, the main 640K memory is the fastest
memory in the system.  This is the memory where all the processing
occurs, that the executable programs are all loaded in, and is also
the memory through which Extended or Expanded memory must be
addressed.  In very simple terms, no amount of Extended/Expanded
memory will make up for an over-crowded main memory area.  Processing
which goes on in the main memory will always be faster than processing
going on indirectly in Expanded memory.  Don't forget that Dbcache is
only providing a way to speed access to data found on your hard disk;
no processing goes on in the cache.  So the bottom line is this: if
the cache is going to take away main memory when that memory is at a
premium, you may find that processing is actually slower with the
cache than without it!   

A rule to all of this is: the cache was provided to use as a tool to
boost performance.  In many configurations Dbcache is not going to
help your performance.  It may confict with your current TSRs or it
may be unnecessary since you already use a fast caching program.  In
those cases simply don't use it.  You aren't required to use it, it's
not a violation of the dBASE Code of Ethics and I certainly won't tell
anyone.   

Dbheap

Another poorly understood tool is Dbheap, a feature which provides a
user-tunable way to allocate memory towards either overlays (which
affects performance in general) or towards memory variable memory
(required for programs, data input screens and such).   

Many users are asking for the perfect number to which Dbheap should be
set in order to get the best performance.  Dbheap defaults at 50 (50%
of the "heap" goes to overlays, 50% to memory variables).   

The heap, essentially, is the free memory available to dBASE IV above
its own needs.  The amount of heap that is available at any one time
is extremely hard to estimate for most with the exception of the
intimately familiar developer.   

Nonetheless, setting Dbheap higher gives more heap memory to memory
variables, setting it lower gives more to overlays.  It would appear
correct to actually lower Dbheap a bit if you only run simple
programs, or if you work primarily from the Control Center since those
operations are not, for the most part, using great amounts of memory
variables but are using dBASE IV itself.  Conversely, if you receive
Insufficient memory messages during the creation of a form or a
report, you'll have to increase Dbheap somewhat to make more memory
available to these processes. 

I'd like to suggest that in the cases outlined up to this point, where
main memory is at a premium, it is imperative to lower Dbheap if
Dbcache is also loaded.  The amount of main memory lost due to the
requirement of the cache software to be loaded may be partially
compensated for by adding more heap memory for overlay usage,
increasing overall performance. 

How much heap you have available is dependent on the amount of free
memory available above that which is used by dBASE IV.  How you tune
the heap is controlled by Dbheap. 

What Dbheap does is determine where the dotted line between memory
variables and overlays is drawn in your own heap memory space.   

We are stating that dBASE IV requires only 450K of memory now instead
of the approximate 516K required in version 1.0.  Where is the actual
50K of additional memory and how can you use it to your advantage? 
Without question, the amount of base memory that dBASE IV actually
occupies (as far as the .exe file itself) is less than 450K.  However,
to function at all, a certain amount of free memory must be used by
the program for various procedures.  This area is going to be called
heap for the purposes of this discussion.  Let's suppose that dBASE IV
itself loads into 400K and the minimum amount of heap required is
50K.  Having 500K free will double the amount of heap available. 
Regardless, a certain chunk of memory is allocated to overlay swapping
and that amount of memory cannot be touched by Dbheap.   So, setting
Dbheap to the maximum value of 100 will still leave a reserved area of
overlay memory.   

Try a little experiment.  At the dot prompt enter,

? MEMORY()

You may notice that the number returned is about the same as it was in
dBASE IV version 1.0.  The reason for this is that the way that the
heap is allocated to memory variables causes the MEMORY() function to
return the same value as before.  But if you try setting Dbheap to 90,
you'll see that you can have 3 times the amount of memory previously
available.  What you are now capable of doing is telling dBASE IV how
you want your precious free memory allocated. 

How should you know how to set it?  I'd suggest that you keep Dbheap
at about 40 until you see that you need the memory for particular
operations.  This way you should be able to get some performance
increase and yet have the capability to increase the amount of free
memory available to memory variables as needed. 

Although you could set Dbheap to 0, the MEMORY() function will return
a number equal to the amount that it would return if Dbheap were set
to 50.

Dbtmp

Finally, let's examine a feature that existed in dBASE IV version 1.0,
but which applies just as much in 1.1.  Dbtmp determines the drive and
directory where the temporary files that dBASE IV creates will be
located.  Once again I will repeat that the hard disk of your computer
is not the fastest place to access files.  Dbcache aids by essentially
speeding up the data swapping from your hard disk into memory through
the use of intermediary memory buffers.  Whenever you start up dBASE
IV, a 300K temporary file is created and is used to swap information
required by dBASE IV itself back and forth from your memory.  This
file is created by default in the directory from which you start dBASE
IV.  However, if you wish, you can create it anywhere you desire, by
using Dbtmp.  

Dbtmp is set as a DOS environmental variable and is normally placed in
the Autoexec.bat file or another .bat file which invokes dBASE IV. 
The syntax is SET DBTMP=<drive>: [<directory>]\

It is important to end the command with a backslash.  The directory is
optional and may not be applicable in the case where a RAM drive is
being used.

On a network, it's recommended to point Dbtmp to your local hard drive
since access to a shared network drive is always slower than access to
local drives.  But the real important trick revealed here is that
setting Dbtmp to a RAM drive (a virtual drive created in the Extended
memory of your computer) may be the single greatest boost to
performance you have at your disposal!  Try this simple test if you
have a RAM drive available: alternately, set Dbtmp to your RAM drive,
then to your local drive.  Place a file into use and display structure
in each case.  You should see a dramatic performance increase with the
temporary files running off of your RAM drive.   

If you have enough RAM (2MB seems to be a popular number), you should
create at least a 600K RAM drive, and dedicate about 1 MB to Dbcache
(assuming that you have a real memory base of 640K loaded only with
DOS to begin with).  You will have the best of both worlds because
your temporary files will be accessed quickly via Dbtmp and your data
files will be accessed quickly via Dbcache.   

If you aren't fortunate enough to have more than 640K on your
computer, you may still benefit by setting Dbtmp to the fastest drive
available to you in your system.   In fact, for those of you with 1 MB
of memory on your motherboard, there's a great use for the extra
384K.  Use it as a RAM drive and direct Dbtmp there.

Summary

Not everyone has an excess of memory available.  Not everyone wants to
set up his computer solely for the optimization of dBASE IV.  Still,
within the bounds of practicality, you might be able to get a lot
better performance out of dBASE IV and not have to change your
configuration so very much.   

If you can, set your Dbtmp variable to a RAM drive for simple and
painless performance optimization.  This is true especially if you
have only a minimum of base 640K memory available.  But remember, you
will need more than just 640K in your machine for a RAM drive.   

It's not likely that you will find a major performance increase by
tweaking the Dbheap setting, however, you may be able to tune it to
aid in providing the optimum amount of memory for your needs while
working in dBASE IV .  This translates to a modest performance
increase anyway and gives you the ability to change, as needed, the
amount of memory available to memory variables that are required in
programs. 

Remember that the cache is not for everyone (even if it is free and
the book says that you can use it to increase your performance).  If
it doesn't seem to help and you've followed the advice of this article
or your support technician, then it's probably time to move on to new
unconquered frontiers.  


