I dearly wanted real Continuations to be faster, because I loathe RetContinuations. They suck. Honest.
There really ought be no difference between a regular continuation and a return continuation. (I certainly can't think of a reason they should be different)
But the most enlightening thing is how much things improved by writing my own small object allocator -- even a quick and dirty one. Last time I was fishing through that subsystem, it seemed to have a lot of overhead. Are there things about it that require this overhead, or could it take an optimization run brining it near the overhead level of this little one? If so, we might have an opportunity to boost parrot's usual speed by a fine degree.
True enough. It's certainly worth poking around with, and since this is all (pleasantly) internal stuff, it's a good place for experimentation and research without affecting user visible behaviour. I fully expect to tweak the object allocator and frame sizes as we get closer to release time.
I looked at the patch and I don't think this is an issue, but we should probably have separate allocation functions for different sized objects, even if they're just macro'd to be the generic allocator function with a hard-coded parameter. That'll let us tweak the allocation system as we go along.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
