Looking over the code for these ops, ISTM that the stack_push and
stack_pop functions which implements them is too bloated.
How often, in practice, is the Stack_cleanup_method cleanup thing
needed?
On those occasions when it is needed, is it ever with a Num, Int, or
Str? Or is it only with PMCs?
When it *is* used, shouldn't the argument be the thing which we've
pushed onto the stack, not the Stack_entry_t* pointer?
Wouldn't it be faster to test whether or not there's a cleanup entry at
pop time, by comparing that field with NULL, than checking whether or
not there's a bit set in flags?
For that matter, the fields part of entry is *only* used to test for the
presence of a cleanup function -- couldn't we eliminate that, in place
of testing cleanup for NULL, and thus save space? If they ever become
necessary for something else, they could of course be added back in
later.
Possibly, the overhead of doing the tests for a cleanup function could
be avoided by making a new Stack_entry_type value, soley for cleanup
functions.
=======================================================================
For a more revolutionary idea for speeding up save[insp] and
restore[insp], consider having a seperate stack for each type, and a
seperate set of stack functions for each type. No 'struck Stack_Entry'
would be needed, since *all* the entries of each stack would be the same
type... thus, no entry_type checking is needed (we know what the type is
due to which function we're in), no flags, no cleanup (a seperate stack
would be used for cleanup functions).
I'm not sure whether or not there are more pros or more cons to this
idea. Comments?
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
