# -----Original Message-----
# From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# Sent: Monday, September 03, 2001 5:50 PM
# To: Brent Dax; Ken Fox
# Cc: Simon Cozens; [EMAIL PROTECTED]
# Subject: RE: Should MY:: be a real symbol table?
#
#
# 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?  Then consider this:

array-of-array pad:
        curpad => a pointer to the current pad; same as in Perl 5
        offs => an offset into the current pad, representing a variable

        Accessing the address of the variable:
                curpad[offs]

stash pad:
        hvaddr => the address of an HE, representing a variable

        Accessing the address of the variable:
                hvaddr->value

Is either of these likely to be faster than the other?  (Although I'm
not an assembler hacker, I can't see the first being faster than the
second.)  If so, does the possible speed benefit outweigh any increased
startup overhead?

# 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.  Similarly,
setting up the hash shouldn't take any more abstract operations than
setting up padlist[0]; the actual hash internals may take more time to
do their job, however.

--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."

Reply via email to