Subj : Re: Persistent storage of compiled scripts
To   : netscape.public.mozilla.jseng
From : Brendan Eich
Date : Thu Jul 22 2004 12:05 pm

Thorsten R wrote:
>>That's right, too -- JS by definition looks up most names at run-time.
>>Only unambiguous local variable and argument names are resolved to stack
>>frame slots at compile-time.
> 
> 
> Whilst this is fine for serializing compiled scripts, it is also a bit
> disappointing. Execution speed would be *much* higher, if pointers were
> stored within scripts.


Pointers are stored within the script to atoms (representing literals, 
including identifiers).  I'm not sure why you believe that execution 
speed would be *much* higher by storing more pointers, since the JS 
language requires names other than unambiguous local variable and 
argument names to be looked up at runtime.

I forgot to mention a change not in JS1.5 RC6a, but in the Mozilla CVS 
trunk: global variable uses that are unambiguous, and that do not refer 
to native object properties with magic getters and/or setters, are also 
optimized to avoid name lookup.  This was done by the patch for bug 
169559 (http://bugzilla.mozilla.org/show_bug.cgi?id=169559).


> Of course this conflicts with garbage collection, so
> I think I understand the reason (do I?).


Not that I can tell ;-).  The problem you seem to want to solve is to 
avoid name lookup at runtime.  SpiderMonkey does that in all cases where 
it can (unambiguous local variable, formal parameter, and engine-created 
global variable uses).


> A curious question: how fast is the
> search for object names, i.e. is it a linear search or are the objects
> arranged in a tree structure or something like that?


I think you are mixing up two things: looking up a property in an object 
uses constant-lookup-time hashing.  Looking up a property along a 
prototype chain uses linear search, but prototype chains are short, and 
in the case where the directly-referenced object has no properties of 
its own yet, the lookup short-circuits to the prototype's scope.  Lookup 
along a scope chain is likewise linear, per ECMA-262, but again scope 
chains are short.

And again, local variable, argument, and simple global variable use 
cases are optimized.


> For JS 2.0: Instead of pointers, isn't there a way possible to store indices
> to tables in compiled scripts, where the tables contain the true pointers to
> objects?


That's essentially what was done by the patch for bug 169559, for global 
variables.

None of this has anything to do with serialization per se. 
Serialization and deserialization of scripts are decoupled from the 
details of optimizing name accesses made by scripts.

/be

.