JavaScriptCore merge & binary compatibility

[Darin Adler]

On Monday, February 17, 2003, at 07:46  PM, Peter Kelly wrote:

> However, after thinking about it  some more I believe we can actually 
> get the same benefit without having the extra Identifier class. The 
> logic for maintaining a pool of identifier names could just as easily 
> live in UString, and we can still keep a set of built-in UString 
> objects around for lengthPropertyName and friends.

This gets some of the optimizations that the Identifier class provides, 
but not all. It's true that having some pre-allocated UString objects 
helps improve speed a lot; one look at the profile will show you that's 
needed no matter what. And having a pool of names would help memory 
footprint, I guess.

But two Identifiers can be compared with ==, no string comparison 
needed. That's not true of two arbitrary UString objects. My records 
from the week we spent speeding up KJS indicates that we saw a 
significant speed improvement (at least 6% on JavaScript iBench) due to 
that change. That was one of the biggest single wins.

I think it's important to judge changes that affect speed by actually 
measuring their impact on the speed of some test cases.

     -- Darin

PS: Here are some of the notes of changes that I made during that week:

- sped up JavaScript iBench by 70% by using a better sort algorithm and 
reducing the number of UString allocations
- sped up JavaScript iBench by 6% by turning ExecState into a simple 
object instead of a two level abstraction
- sped up JavaScript iBench by 7% by turning the property map into a 
hash table and improving String instance handling
- sped up JavaScript iBench by 6% by hoisting the property map into 
ObjectImp and doing less ref/unref
- sped up JavaScript iBench by 1.5% by converting integers into strings 
with custom code rather than sprintf
- sped up JavaScript iBench by 2% by using masking instead of modulus 
in the property map hash table code
- sped up JavaScript iBench by 3% by improving the implementation of 
the "perfect hashing" hash tables used for static properties
- sped up JavaScript iBench by 1.5% by storing computed hash values in 
the UString representation so we don't recompute them
- sped up JavaScript iBench by 6.5% by atomizing property identifiers
- sped up JavaScript iBench by 1.5% by not clearing and rebuilding the 
list each time during sorting
- sped up JavaScript iBench by 5% by decreasing the amount of ref/deref 
done by changing interfaces so they can deal directly with ValueImp
- sped up JavaScript iBench by 1% by making lists ref/unref less
- sped up JavaScript iBench by 7.5% by creating argument list objects 
only on demand rather than for each function call
- sped up JavaScript iBench by 3% by allocating the ActivationImp 
objects on the stack rather than in the garbage-collected heap
- sped up JavaScript iBench by 11% by turning the scope chain into a 
singly-linked list that shares tails rather than a non-sharing 
doubly-linked list with subtly different semantics
- sped up JavaScript iBench by 10% by changing the List class from a 
linked list to a vector, and using a pool of instances

Because this comes from my personal notes, it doesn't include the many 
other speedups that Maciej did the same week.