[Webkit-unassigned] [Bug 49739] WebIDL attributes should be implemented as getters and setters on the prototype object.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=49739





--- Comment #7 from Oliver Hunt <oliver at apple.com>  2011-06-19 13:21:03 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > Do we have an idea about how to do this without slowing down DOM property access in the common case?
> > > 
> > > This is probably better answered by someone who knows JSC better but isn't this just the same as accessing normal JavaScript objects that have getters on their [[Prototype]]?
> > > 
> > > How do you optimize getters/setters today?
> > > 
> > > How do you optimize [[Get]] when present on a [[Prototype]]?
> > 
> > My question is not if/how to optimize getters on a prototype, but rather, if we can make this change without a regression in performance (through some witchcraft).  The answer is probably no.
> 
> I'm unsure how much impact this will have on setters, as i'm 90% sure that setters are completely uncached currently.

Correction: I know that setters aren't cached.  Assigning to dom properties would be hammered, but they are theoretically already slow.  If we added caching to setters we would probably end up with a net win.

> 
> Getters will be hit by additional branches to validate the proto chain which is unfortunate.

This will suck, but given that they're getter/setter pairs that we provide we might be able to remove at least _a_ branch from the current cached path.  We should also be able to avoid constructing an actual function wrapper until we absolutely have to (getOwnPropertyDescriptor requires us to provide the function object)

> 
> The big change will be the property accessors in the dom will need to do type checks and that's an additional virtual call.  Could be fixed if class info was hung off of structure but then Structure becomes much larger. :-/
>

A virtual call is no longer necessary but there's still going to be an additional (unavoidable) cost here, but also we'll nee to go through _every_ custom getter or setter and ensure correct behaviour.  

> Additionally JSC API probably won't be able to do this for custom getters, etc
This has been dealt with already by geoff -- API objects kill optimisation :(

> 
> I believe classes with index property accessors are going to magically become proxies, but i don't believe the semantics for that is sufficiently described yet.

This is really an issue that needs to be resolves -- do index properties move to the prototype or do they stay own properties?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.