--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
# -----Original Message-----
# From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# Sent: Monday, September 03, 2001 7:25 PM
# To: Brent Dax; Ken Fox
# Cc: Simon Cozens; [EMAIL PROTECTED]
# Subject: RE: Should MY:: be a real symbol table?
#
#
# At 07:05 PM 9/3/2001 -0700, Brent Dax wrote:
# ># From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# ># At 05:30 PM 9/3/2001 -0700, Brent Dax wrote:
# ># >As far as expensiveness, I think this can be just as fast as
# ># our current
# ># >offset-into-the-pad method.
# >#
# ># I was speaking in both speed and memory use when I was
# talking about
# ># expense. We'd need to maintain a hash structure for each pad,
# ># plus we'd
# ># need to either design the hash structure such that it didn't
# ># need absolute
# ># addresses (so we could build it at compile time, which could
# ># be a long time
# ># before runtime with a disk freeze or two and an FTP in the
# ># interim), or
# ># we'd need to patch the addresses up at runtime when we
# ># allocated a new pad.
# >
# >I assume we're willing to have more fixup time for runtime
# performance,
# >correct?
#
# Yes. But fixup is a runtime cost, so we need to weigh what
# the fixup costs
# versus the return we get from it.
But it's a one-time runtime cost, unlike, say, a string eval in a loop.
(sub-entry overhead complaints cut--they'll be addressed at the end of
the e-mail.)
# ># I'm not convinced the memory usage, and corresponding time to
# ># clone and/or
# ># set up the hash-based pad, is worth the relatively
# infrequent by-name
# ># access to variables in the pad. I could be wrong, though.
# ># We'll have to try
# ># it and see. (Shouldn't affect the bytecode, however, so we can try
# ># different methods and benchmark them as need be)
# >
# >By using something similar to temp() (where the SV* is temporarily
# >replaced), cloning should only be necessary for situations
# in which two
# >threads are running the same function at the same time.
#
# Nope, I'm talking about recursion. When you do:
#
# sub foo {
# foo();
# }
#
# we need to clone foo's pad from the template, because we need
# a new one.
# Otherwise that whole lexical variable/recursion thing doesn't
# work, which
# is A Bad Thing. :)
Now is where the temp() stuff I was talking about earlier comes in.
sub foo {
my($bar);
foo();
}
is basically equivalent to
sub foo {
temp($MY::bar);
foo();
}
(I mentioned to Ken Fox in private that this isn't too different than
temp()ing globals when each sub is in its own package.)
If we did this, I don't think the cost would be greater to recurse than
it would be for array-of-arrays. (Especially since we'd make sure to
optimize the hell out of temp.) This would also lead to less code to
write and a smaller binary. Plus a simple way to do static: don't
temp()orize the variable on entry.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
