Changeset 1791 in webkit for trunk/JavaScriptCore/kjs/value.h

Timestamp:

Aug 9, 2002, 9:31:50 PM (23 years ago)

Author:

darin

Message:

JavaScriptCore:

Some string speedups. Makes sony.com cached 11% faster.

• kjs/ustring.h: Made it possible for UChar objects to be uninitialized, which gives a speed boost. Inlined CString's +=, UString's destructor, +=, and +.
• kjs/ustring.cpp: (UString::UString): Optimize const char * version, which showed up heavily in performance analysis. Added new two-UString version, which makes the + operator fast. (UString::ascii): Remove thread safety changes. Change static buffer to remember its size, and to always be at least 4096 bytes long; that way we never have to reallocate unless it's for a long string. Also make code to extract the characters significantly faster by getting rid of two pointer dereferences per character. (UString::is8Bit): Avoid one pointer dereference per character. (UString::toDouble): Use ascii() instead of cstring() to avoid copying the string.

• kjs/collector.cpp: Remove unneeded APPLE_CHANGES.
• kjs/regexp.cpp: Remove ifdefs around some APPLE_CHANGES that we want to keep, because they just fix warnings.
• kjs/value.h: Remove obsolete APPLE_CHANGES comment.

• JavaScriptCore.pbproj/project.pbxproj: Project Builder decided to move a line around in the file.

WebCore:

• force-clean-timestamp: JavaScriptCore headers changed that require a full build here.

File:

• trunk/JavaScriptCore/kjs/value.h (modified) (1 diff)

trunk/JavaScriptCore/kjs/value.h

@@ -95 +95 @@
     virtual ~ValueImp();
 
-#ifdef APPLE_CHANGES
-    // The collector lock is not locked around the ref() and unref()
-    // methods for the following reasons:
-    //
-    // - The only cases where changing the refcount could possibly
-    // affect the collector's behavior is incrementing from 0 to 1,
-    // and decrementing from 1 to 0.
-    //
-    // - In the 0 to 1 case, the GC allowed flag will always be off
-    // beforehand, and set right afterwards. And setting it grabs the
-    // collector lock. So if this happens in the middle of GC, the
-    // collector will see either a refcount 0 GC not allowed object,
-    // or a refcount 1 GC not allowed object, and these cases are
-    // treated exactly the same.
-    //
-    // - In the 1 to 0 case, the only possible bad effect is that the
-    // object will live for one GC cycle longer than it should have
-    // to, which is really not so bad.
-    //
-    // - In theory on some platforms increment or decrement could make
-    // other threads see intermediate values that are different from
-    // both the start and end value. If that turns out to really be
-    // the case we will have to reconsider this scheme.
-#endif
     inline ValueImp* ref() { refcount++; return this; }
     inline bool deref() { return (!--refcount); }