Jürg Lehni Reporter
	Description • 11 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Steps to reproduce:

In this performance test, I compare various methods of storing and accessing a value on an object: http://jsperf.com/data-vs-accessor-vs-getter-setter/2

- data properties
- accessor properties on the object itself
- accessor properties on the object's prototype
- getter / setter functions



Actual results:

Firefox performs extremely well in all of the tests except one: When using accessor properties on the object itself, it shows a slow-down in the range of factor 130 over the other methods, wich is extreme.

The optimizer appears to be able to fully inline the code of all other situations, leading to no slow down at all over the plain data property access, which is very impressive. SpiderMonkey currently beats both V8 and JavaScriptCore in all other tests, but is by far the slowest in this one test.


Expected results:

The huge performance difference to the very similar situation where the accessor property is accessed on the prototype (which actually should be slower since the prototype chain is involved) is hard to understand.

It looks like a bug affects the performance of the accessor property access on the object itself, perhaps avoiding any type of optimization.

	Jürg Lehni Reporter
	Comment 1 • 11 years ago

I just tested this on the 29 branch, and while the speed improvements there are simply impressive, accessor properties on the object itself is still a slouch, and its performance actually decreased even more in relation to the 26 branch.  It now appears to be ~500 times slower than the plain data property.

	Till Schneidereit [:till]
	Comment 2 • 11 years ago

Hey Jürg, thank you for submitting this report. We are aware of the issue, and it is tracked in a few bugs already: bug 782913 and bug 626021.

I'm going to mark this one as a duplicate of 782913 to prevent increased forking of discussions.

	Jürg Lehni Reporter
	Comment 3 • 11 years ago

Hi Till, thanks for pointing me to these other bugs. I did run a search but used different terminology. 

Perhaps the discovery of the huge difference between accessors on objects versus their prototype is of importance in the discussion? It seems that SpiderMonkey can already optimize accessors, but only if they're on the prototype.

	Jürg Lehni Reporter
	Comment 4 • 11 years ago

Ok, I just saw that this is already discussed in bug 861759. You can ignore my comment from before.

	Till Schneidereit [:till]
	Comment 5 • 11 years ago

That is what I meant with forked discussions: this is already pretty hard to follow. :)

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 11 years ago

Jürg, one note on the jsperf tests.  I'm 99% sure that Spidermonkey is just loop-hoisting at least the gets, so it's not clear to me that the get numbers there are that meaningful.  The change from 26 to 29 is probably due to the fix for bug 946425 making empty loops of the form jsperf uses faster...

	Jürg Lehni Reporter
	Comment 7 • 11 years ago

Thanks for pointing this out. I've since switched to more meaningful tests and indeed what I measured in the test linked above doesn't quite add up there. But the differences within one browser still seem valid.