JavaScriptCore merge & binary compatibility

[Peter Kelly]

What we can do there is add a flag to UString::Rep to indicate whether or
not it's in the string pool. Then when doing a comparison we can check    
this and if it's set just compare the pointers. e.g.:

bool operator==(const UString& s1, const UString& s2) 
{
  if (s1.rep->inpool && s2.rep->inpool) // currently the case with all    
                                        // Identifier objects
    return (s1.rep == s2.rep)
  else {
    // normal string compare
  }
}  
 
As long as all of the appropriate strings used in kjs are stored in the
pool (could possibly be done in the UString constructor, although it may 
not be necessary in some cases), this should give the same performance
for comparison as Identifier.

On Mon, 17 Feb 2003, Darin Adler wrote:

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

-- 
Peter Kelly
pmk@kde.org