On Mon, Jul 22, 2002 at 02:47:01PM -0400, Tanton Gibbs wrote:
The RECALL command automates that so that set_string now looks like:
void set_string( PMC* value ) {
CHANGE_TYPE( pmc, PerlString );
RECALL;
}
will be turned into the correct code shown above. By
using the RECALL
Sure, that's pretty trivial to fix. What is the general concensus.
REINVOKE is fine with me, does that sound good?
- Original Message -
From: [EMAIL PROTECTED]
To: Tanton Gibbs [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 23, 2002 8:37 PM
Subject: Re: pmc RECALL command
[EMAIL PROTECTED]:
# On Mon, Jul 22, 2002 at 02:47:01PM -0400, Tanton Gibbs wrote:
#
# The RECALL command automates that so that set_string now looks like:
#
# void set_string( PMC* value ) {
#CHANGE_TYPE( pmc, PerlString );
#RECALL;
# }
#
# will be turned into the correct code
Tanton Gibbs sent the following bits through the ether:
I implemented a RECALL preprocessor directive for the pmc classes.
...
Thus ensuring that the correct semantics always occur.
I'm afraid I don't quite understand what RECALL is supposed to do.
Can you explain it in a little more detail?
Sure,
the basic problem is that in perlint.pmc we have something like:
void set_string( PMC* value ) {
CHANGE_TYPE( SELF, PerlString );
SELF-data = value-data
}
In other words implement a COW strategy after being changed into a
PerlString. However, in perlstring.pmc
the following is
On Sat, Jul 20, 2002 at 10:23:45PM -0400, Tanton Gibbs wrote:
without the recall it performs in: 16.055 seconds
with the recall it performs in: 16.722 seconds
So, it slowed it down 6.5 tenths of a second after 10,000,000 times. That
is not too bad for ensuring correct semantics.
What
