"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_stack call and re-run these numbers?
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 were made Copying a total of 72819800 bytes There are 21 active Buffer structs There are 1024 total Buffer structs This compares to the 14th July CVS version: 5000 generations in 81.172149 seconds. 61.597482 generations/sec A total of 58389 bytes were allocated A total of 160793 DOD runs were made A total of 1752 collection runs were made Copying a total of 1228416 bytes There are 81 active Buffer structs There are 192 total Buffer structs > 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 performance has to halve in order to implement such features, I hope somebody plans to write Parrot::Lite! -- Peter Gibbs EmKel Systems
