> > If performance has to halve in order to implement such features, I hope
> > somebody plans to write Parrot::Lite!
>
> I'm not sure if I understand the problem properly, but is the problem with
> using exceptions (or using longjmp) and the like to unwind that we can't
> trust external extension
> With the call to trace_system_stack commented out in dod.c, I get 48.5
> generations per second. The full stats are:
> 5000 generations in 103.185356 seconds. 48.456488 generations/sec
> A total of 36608 bytes were allocated
> A total of 42386 DOD runs were made
> A total of 6005 collection runs
On Wed, Jul 24, 2002 at 10:38:09PM +0200, Peter Gibbs wrote:
> "Mike Lambert" wrote:
> > I know that there are faster solutions to the problem of child collection,
> > but Dan doesn't want to use them due to the problems that occur when we
> > start using exceptions (and longjmp, etc).
>
> If pe
"Mike Lambert" wrote:
> - addition of stack-walk code to avoid child collection
> - the GC refactoring I commited
> I suspect the former is what is causing your speed hit, although I'm not
> ruling out the possibility that my changes caused a problem as well. Can
> you disable the trace_system_st
Hey Peter,
Sorry about not replying to your ealier message...I completely forgot
until I saw this message. :)
> Thanks Mike, those changes do indeed help. Current numbers on my system for
> 5000 generations of life with various versions of Parrot (using CVS tags)
> are:
> 0.0.5 47.99 genera
"Mike Lambert" wrote:
> I've just committed some changes tonight that improved performance
> on the GC-heavy tests in examples/benchmarks/ by about 8%.
Thanks Mike, those changes do indeed help. Current numbers on my system for
5000 generations of life with various versions of Parrot (using CVS
I've just committed some changes tonight that improved performance
on the GC-heavy tests in examples/benchmarks/ by about 8%.
Results on each of the GC benchmark tests are, scaled against 1.0 as the
old version, are:
old new
gc_alloc_new.pbc1.00
