GC/DOD feedback & runtime tuning

[Dan Sugalski]

I've been playing with a few test programs, and I'm finding it depressingly easy to get perl 5 to beat the pants off of Parrot for runtime speed, often by a factor of 4, regularly by a factor of two. There are a number of trouble spots that we can address now, without affecting anything else that's going on.

First, the resource system falls down hard when doing lots of allocations with no deallocations. It gets exponentially slower, which is a Bad Thing. While I'm not sure that there's a whole lot to be done about this in the grand scheme, the current system can certainly use some feedback mechanisms to deal with the problem for reasonable (<100K live objects) data set sizes.

Second, Array and its subclasses need some performance thumping, as they seem to come in at about half the speed of perl 5. I'm not sure where the speed penalty comes in, whether it's in the class code or in the design of the access mechanisms, but I want to find out why, and fix it *now*. If it's a design problem, I want to know so we can redesign before too much is dependent on the current scheme, and if it's an implementation tuning issue that can be dealt with by anyone with some time and an inclination to abuse the code.

I'll check in the stress programs and their perl 5 counterparts so we can have some sort of feel for time issues on this.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk