Mmm I'm wondering here if you need to adjust the garbage collector.
Right now the VM (unix/mac/windows) will
grow memory by a set amount, or the amount needed plus slack. Once
it's  grown and we exceed a threshold it
and memory in new space comes free we will shrink things. This is
controlled by vmParameter 24 and 25.
Bad choices lead to overhead as we grown/shrink memory allocated to
the  VM. Not that we point out what our 'good' choices are
in any case.
> Smalltalk vmParameterAt: 25 put: 24*1024*1024. "grow headroom"
>  Smalltalk vmParameterAt: 24 put: 48*1024*1024.  "shrink threshold"
The other magic numbers are 5 & 6 which control when a incremental GC
is created, and when we tenure objects.
So for example if I know I'm going to create a bunch of points
(100,000+) I might consider changing this to at 5 put: 50,000
at 6 put 40,000.  The trade off here is how long it will take to trace
 50,000 live objects. Although machines are so fast
now perhaps we need to revisit this.  {I'm sure for years now I've
considered rewriting the logic a bit so we can adapt the values
to machine characteristics, since these values were chosen to give
25mhz mac 68040 machines  minimal igc times so that music
playback would work without stuttering}
Since I'm speak on this topic at Smalltalk Solutions 2004 perhaps it's
 time for some coding...
/* Defaults found in the image */
SmalltalkImage current  vmParameterAt: 5 put: 4000.  "do an
incremental  GC after this many allocations"
SmalltalkImage current  vmParameterAt: 6 put: 2000.  "tenure when more
 than this many objects survive the GC"
I will note I looked at this last summer and found for the base image,
 and what people normally do, altering the current values
doesn't perhaps buy you anything. The values chosen, are reflective of
 the work you are doing.
Plus of course is how we look at the remember table. Old objects that
point to new Objects. If you get a large collection into that logic
we spin thru all the elements (millions?) when an igc occurs. This can
 be solved by either: rewritting the GC logic, or doing a full GC
in the right place so things get tenured. Mind having adaptive
feedback  from the GC logic watching for this would work too {See
John's list of  things to do someday}
I'll suggest if you can create all your objects, do a full GC, then do
 the computations, that might improve things.
 VM parameters are numbered as follows:
  1 end of old-space (0-based, read-only)
  2 end of young-space (read-only)
  3 end of memory (read-only)
  4 allocationCount (read-only)
  5 allocations between GCs (read-write)
  6 survivor count tenuring threshold (read-write)
  7 full GCs since startup (read-only)
  8 total milliseconds in full GCs since startup (read-only)
  9 incremental GCs since startup (read-only)
  10 total milliseconds in incremental GCs since startup (read-only)
  11 tenures of surving objects since startup (read-only)
  12-20 specific to the translating VM
  21 root table size (read-only)
  22 root table overflows since startup (read-only)
  23 bytes of extra memory to reserve for VM buffers, plugins, etc.
  24 memory headroom when growing object memory (rw)
  25 memory threshold above which shrinking object memory (rw)"