Bug 20928 - Speed up JS property enumeration by caching entire PropertyNameArray
Summary: Speed up JS property enumeration by caching entire PropertyNameArray
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-18 17:21 PDT by Sam Weinig
Modified: 2008-09-19 19:25 PDT (History)
0 users

See Also:


Attachments
cache entire PropertyNameArray (19.52 KB, patch)
2008-09-18 23:36 PDT, Sam Weinig
darin: review-
Details | Formatted Diff | Diff
updated patch (20.89 KB, patch)
2008-09-19 16:41 PDT, Sam Weinig
no flags Details | Formatted Diff | Diff
updated (19.92 KB, patch)
2008-09-19 17:50 PDT, Sam Weinig
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Weinig 2008-09-18 17:21:46 PDT
We can speed up JavaScript property enumeration (for .. in) by caching the entire PropertyNameArray in the StructureID instead of just the properties in the PropertyMap.
Comment 1 Sam Weinig 2008-09-18 23:36:34 PDT
Created attachment 23556 [details]
cache entire PropertyNameArray
Comment 2 Darin Adler 2008-09-18 23:45:06 PDT
Comment on attachment 23556 [details]
cache entire PropertyNameArray

JSPropertyNameIterator::invalidate is so simple now it should probably be inlined. Maybe also use clear() instead of assigning 0?

+    , m_data(0)

Don't need that for RefPtr.

+inline JSPropertyNameIterator::JSPropertyNameIterator(JSObject* object, PropertyNameArrayData* propertyNameArrayData)

Should PropertyNameArrayData* should be PassRefPtr, since this takes ownership.

+        void setCachedPrototypeChain(StructureIDChain* cachedPrototypeChain) { m_cachedPrototypeChain = cachedPrototypeChain; }

+        void setData(PropertyNameArrayData* data) { m_data = data; } 

Should be PassRefPtr since these take ownership.

+        if ((*a).get() != (*b).get())
+            return false;

These would read better with -> but can't you just omit the get() altogether?

+        if (!(*a).get())
+            return true;

This would read better with -> but can't you just omit the get() altogether?

+    ASSERT_NOT_REACHED();
+    return false;

This will just create a warning on Windows and make the build fail. Leave it out.

+    // FIXME: This breaks the optimization for the JSGlobalObject. 

I think you should write a clearer comment. Does this really need a FIXME?

I'm going to say review- because of the number of actionable comments.
Comment 3 Sam Weinig 2008-09-19 16:40:20 PDT
(In reply to comment #2)
> (From update of attachment 23556 [details] [edit])
> JSPropertyNameIterator::invalidate is so simple now it should probably be
> inlined. Maybe also use clear() instead of assigning 0?
> 
> +    , m_data(0)
> 
> Don't need that for RefPtr.

Fixed.

> 
> +inline JSPropertyNameIterator::JSPropertyNameIterator(JSObject* object,
> PropertyNameArrayData* propertyNameArrayData)

Fixed.

> 
> Should PropertyNameArrayData* should be PassRefPtr, since this takes ownership.
> 
> +        void setCachedPrototypeChain(StructureIDChain* cachedPrototypeChain) {
> m_cachedPrototypeChain = cachedPrototypeChain; }
> 
> +        void setData(PropertyNameArrayData* data) { m_data = data; } 
> 
> Should be PassRefPtr since these take ownership.

I don't think this is true, because the ownership is actually shared.

> 
> +        if ((*a).get() != (*b).get())
> +            return false;
> 
> These would read better with -> but can't you just omit the get() altogether?
> 
> +        if (!(*a).get())
> +            return true;
> 
> This would read better with -> but can't you just omit the get() altogether?

Fixed

> 
> +    ASSERT_NOT_REACHED();
> +    return false;
> 
> This will just create a warning on Windows and make the build fail. Leave it
> out.
> 

Fixed.

> +    // FIXME: This breaks the optimization for the JSGlobalObject. 
> 
> I think you should write a clearer comment. Does this really need a FIXME?

Removed.

> 
> I'm going to say review- because of the number of actionable comments.
> 

Comment 4 Sam Weinig 2008-09-19 16:41:01 PDT
Created attachment 23585 [details]
updated patch
Comment 5 Sam Weinig 2008-09-19 17:50:34 PDT
Created attachment 23588 [details]
updated
Comment 6 Darin Adler 2008-09-19 17:56:57 PDT
Comment on attachment 23588 [details]
updated

r=me

We discussed some things you forgot to do in person, and I think it would be good to do them, but the patch is super-great to land even as-is.
Comment 7 Sam Weinig 2008-09-19 19:25:28 PDT
Fixed in r36694.