Amortization is the process of averaging out initial/startup
cost over the course of utilization.

In analysis we sometimes amortize certain operations using
cyber-dollars (or so your author would have you believe).

/*
 * Dynamic Array Re-Allocation
 * ***************************
 *
 * When you have a dynamically allocated array of objects
 * and realize that you are going to need ~more~ space,
 * you'll need to re-allocate the array!
 *
 * The process is simple, but highly prone to error!  Be
 * careful!!!
 *
 *    -- attempt to allocate new space
 *    -- if successful,
 *       -- copy old data over to new space
 *       -- deallocate old space
 *       -- re-point pointer
 *       -- null-out temporary pointer
 *       -- update length/size counter(s)
 */

/*
 * To decide how many more elements to allocate, one of two
 * schemes is typically chosen:
 *
 *     common sized chunks
 *     common multiplier
 *
 * With a chunk you'll always see a 'size+=CHUNK;' and
 * allocate '[size+CHUNK]' at the top.  (Also known as an
 * arithmetic growth scheme.)
 *
 * With the multiplier, you'll instead see 'size*=MULT;' and
 * allocate '[size*MULT]' at the top.  (Also known as a
 * geometric growth scheme.)
 *
 * Chunk sizes are typically determined by statistical
 * analysis of a program's typical data.  The most common
 * multiplier is 2.
 *
 * These schemes keep OS overhead to a minimum but only the
 * multiplier scheme amortizes the cost of reallocation.
 * (The chunked scheme doesn't put off enough work for
 * later.)
 *
 * ************************************************************
 *
 * If the user's memory needs wane during the program's
 * continued execution, you can even shrink your dynamic
 * array.  Try not to do this too soon, however.
 * 
 * (In a chunked system, wait until the used is two chunks
 * less than the allocated size before reallocating ~one~
 * chunk smaller.  This will allow for re-growth should the
 * user's needs change back.)
 *
 * Oh, in a multiplier system, wait until the used size is
 * two multiples back from the allocated size before
 * shrinking by ~one~ multiple.  So, if the current
 * allocated size is 64 under a 2 multiplier, wait until the
 * used is 16 rather than just 32.  At that time you would
 * shrink to 32 -- leaving room for future growth.
 *
 * This pessimistic shrinkage makes sure the amortization of
 * OS interaction is continued here as it was done in
 * growth.
 */