> > 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
