Aaron Bohannon wrote:

> In order to prevent irregular GC pauses, I decided to try inserting
> a call to Gc.compact once per loop.  I was hoping the overall
> throughput wouldn't suffer too badly.  To my very pleasant surprise,
> I found the throughput *increased* by about 2%!!  So in a 15 second
> run (with no idle time, as I said), it now does about 130 heap
> compactions instead of 3 and gets better total performance because
> of it, utterly defying my GC intuition.

As Damien said, maybe the original code ran into a bad case of free
list fragmentation which the compactor cured.  But maybe the 2% is
just measurement noise.  Some of my favorite horror stories about
timings:

http://www-plan.cs.colorado.edu/diwan/asplos09.pdf
  "We see that something external and orthogonal to the program,
   i.e., changing the size (in bytes) of an unused environment variable,
   can dramatically (frequently by about 33% and once by almost 300%)
   change the performance of our program."

http://compilers.iecc.com/comparch/article/96-02-165
  [ Execution speed for the same binary varies by a factor of 2
    depending on cache placement ]

I have also personally observed speed differences of 20% just from
inserting or deleting dead code in a program...

- Xavier Leroy