On Wed, May 29, 2002 at 02:08:25AM -0400, Mike Lambert wrote:
> gc_generations.pbc
> me trying to simulate behavior which should perform exceptionally
> well under a genertaional collector, even though we don't have one :)
> each memory allocation lasts either
> a long time, a medium time, or
On Wed, 29 May 2002, Mike Lambert wrote:
> Hey all,
>
> After finding out that life.pasm only does maybe 1KB per collection, and
> Sean reminding me that there's more to GC than life, I decided to create
> some pasm files testing specific behaviors.
>
> Attached is what I've been using to test a
> > > gc_alloc_new.pbc
> > > gc_alloc_reuse.pbc
> >
> > I don't think these two tests are very interesting. They allocate
> > quite large strings, so they don't put much strain on the GC.
> > Instead, they measure how fast Parrot is at copying strings.
>
> I believe that's a very good thing to be
> > gc_alloc_new.pbc
> > gc_alloc_reuse.pbc
>
> I don't think these two tests are very interesting. They allocate
> quite large strings, so they don't put much strain on the GC.
> Instead, they measure how fast Parrot is at copying strings.
I believe that's a very good thing to be testing. If the
On Wed, May 29, 2002 at 02:08:25AM -0400, Mike Lambert wrote:
> gc_alloc_new.pbc
> allocates more and more memory
> checks collection speed, and the ability to grow the heap
>
> gc_alloc_reuse.pbc
> allocates more memory, but discards the old
> checks collection speed, and the ability to reclaim
Hey all,
After finding out that life.pasm only does maybe 1KB per collection, and
Sean reminding me that there's more to GC than life, I decided to create
some pasm files testing specific behaviors.
Attached is what I've been using to test and compare running times for
different GC systems. It's
