Bug 31756 – getter/setter performance is much worse then a function call

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Joseph Pecoraro]

Created attachment 43629 [details]
[TEST CASE] Check Console for Timed Results

Running the Attached Test Case shows getters/setters are slower then function calls. Is there are particular reason for this or could the performance be matched?

My Results:

  getter: 49ms
  get function: 6ms

  setter: 56ms
  set function: 6ms

[Oliver Hunt]

Accessor properties are uncachable.  I have filed a bug on this before.  But accessors are also basically a  bad thing, irrespective of performance.

[Sam Weinig]

(In reply to comment #1)
> Accessor properties are uncachable.  I have filed a bug on this before.  But
> accessors are also basically a  bad thing, irrespective of performance.

Why is this the case?

[Oliver Hunt]

(In reply to comment #2)
> (In reply to comment #1)
> > Accessor properties are uncachable.  I have filed a bug on this before.  But
> > accessors are also basically a  bad thing, irrespective of performance.
> 
> Why is this the case?

We can cache the lookup, but we need to make a call -- the memory cost of planting sufficient logic to handle this is substantial.  However Gavin and I have been thinking of a way to rectify this.

[Gavin Barraclough]

We should just be able to generate dynamic stubs that performs the call for an accessor-access (much like a prototype or chain access).  As a first cut, these could be cached uniquely per access site (again, as for prototype & chain lookups).  If we make this a small stub that calls on to an asm routine to perform the actual method invocation this may be a sufficient solution; if these stubs were to prove to large then this approach might have too great an overhead, and we'd want to look at caching the getter/setter stubs with the getter/setter they cache access to, so that they can be shared across uses.  This caching would slightly complicate the implementation.

I'd be quite keen to see this happen (I quite like the language feature), but to find time to devote to this I think we'd need an example of a major website, benchmark or piece of functionality in the browser being impaired by this.

G.

[Sam Weinig]

One place we use getter/setters a lot is in the Web inspector, so speeding them up would probably be a perf win for it.

[Brian Burg]

Now that 5 years have passed, where are we w.r.t. accessor performance? What tiers optimize accessors? Do we have a better idea of how to speed this up?

Accessors are still used throughout the inspector, and in plenty of real world code.

[Filip Pizlo]

(In reply to comment #6)
> Now that 5 years have passed, where are we w.r.t. accessor performance? What
> tiers optimize accessors? Do we have a better idea of how to speed this up?
> 
> Accessors are still used throughout the inspector, and in plenty of real
> world code.

This has been fixed for months now. I don't remember the revision. 

There should be no difference between function call performance and accessor performance except in the interpreter.

[Brian Burg]

Awesome, thanks.