[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: global environment special case
- From: Paul Bleisch <pbleisch@...>
- Date: Thu, 20 Apr 2000 12:18:42 -0500
A "next" fallback would be great as it would all one to
support generic container objects that are actually C/C++
objects. i.e. COM enumerators.
> -----Original Message-----
> From: David Jeske [mailto:firstname.lastname@example.org]
> Sent: Thursday, April 20, 2000 12:04 PM
> To: Multiple recipients of list
> Subject: Re: global environment special case
> Even if it's not possible to change the implementation of the
> globals-table to match other tables, it would be nice if it would
> "look like" other tables for operations.
> Off the top of my head, I think the changes required would be
> (a) a way to "get" the global table reference, such as the
> "getglobaltable()" function which has been mentioned, or perhaps some
> special symbol in the language.
> (b) an implementation of "next" as a fallback method so that walking
> the global table could be made to look like walking any other table
> through the fallbacks, even though it's implementation was different.
> Which sounds like a generally "good idea" (tm) to me. However, a few
> days ago when I started thinking about the "next" fallback idea, it
> seemed pretty non-trivial to make work fast.
> On Thu, Apr 20, 2000 at 11:15:31AM -0300, Roberto Ierusalimschy wrote:
> > > Can you explain how much this experiment tells us? You've added
> > > bytecodes, etc., so I'm not surprised it's slower. [...]
> > This is only a back of the envelope estimation. The
> original loop has 10
> > opcodes, the new one has 13, so are not the opcodes that make the
> > difference of more than 50% in run time. Also, my "global"
> table in the
> > experiment has only one element; a real one would have some
> hundreds (at
> > least 100 from predefined and library functions). (We need
> an average of 1.5
> > probes to access such table).
> > Of course there are many ways to improve its efficiency
> (implicit access to
> > the global table in the opcode, special access method for
> strings, etc),
> > but we will loose some performance at the end. As I said, we will
> > try a real implementation to get a better estimate.
> > (Another advantage of using a table for globals: you can
> change the whole
> > global environment with a simple assignment.)
> > -- Roberto
> David Jeske (N9LCA) + http://www.chat.net/~jeske/ + email@example.com