Trucchi: I guess they really wanted to be told “Go forth and use getters and setters!”
Gillman: So its for sure a good invested time
Sleiman: Tcsc: getters/setters are optimised now, in v8, *usually*
Makela: Tcsc: they should be. Just like methods. But different features might deoptimise them if they ever interact.
Quilindrino: It’s probably harder to tell, because less people use getters/setters
Berkheimer: Yeah, i mean i don’t see why they couldn’t be implemented efficiently
Trucchi: I can see it complicating hidden cl***es
Defranco: Hm, I think hidden cl***es only track properties, not types
Shoto: But it’s certainly going to be slower if the VM can’t inline it. Much slower
Menendez: And most of the ways people use getters/setters are pretty much useless. Things like get foo{ return _foo } are too bug prone, and make the VM do more work for no benefit
Castellan: My experience was that it was pretty awful for performance. i think it deoptimized most of my program because i saw a 3-4ms/frame difference in performance after removing them
Thoeny: But that was a while ago.
Sevenbergen: Oh, v8 did use to be really bad at them, yes
Vere: Not sure about other VMs
Whitmer: I guess nobody really put much effort into optimising getters/setters because nobody uses them anyway
Trucchi: Dekok: well, tehy track property types, don’t they?
Rabern: Trucchi: probably separately.
Trucchi: Hm. I was under the impression that if you had var obj = { foo: ‘somestring’ }, that doing obj.foo = 5 would end up creating a new hidden cl***
Rouillier: That would be interesting to know
Ryant: I could see it working either way.
Sholl: I suspect it doesn’t create a new hidden cl***
Waszak: But it might weird out the other parts of the compiler that deal with type information
Swainey: Trucchi: hidden cl***? I believe hidden cl*** is a uniquely V8 quality dealing with array optimization
Negron: Spidermonkey and jsc do the same thing but call them shape or map or something
Mcdorman: And it doesn’t have to do with arrays
Bez: Trucchi: I don’t think it does
Xu: Austincheney: hidden cl***es are a technique for optimising property access in dynamic languages.
Trygg: Erm, in prototype-based dynamic languages*
Ivancevic: Http://www.html5rocks.com/en/tutorials/speed/v8/ if anybody else wants more information
Whaltey: It also helps with PIC
Trucchi: Dekok: hmm I might be conflating it with the way it optimizes arrays, since the v8 docs don’t mention property type, just property names and existence https://developers.google.com/v8/design?hl=en#fast-property-access
Cedano: And PIC = Polymorphic Inline Caching, not Position-Independent Code
Sirhan: Iirc luajit just sinks the table accesses for static keys instead of doing hidden cl***es or anything like it
Lecates: I think you’d have cache problems by doing that but maybe not
Vecellio: Interesting. I still haven’t looked at the design of LuaJIT
Jeanclaude: Yeah, he mentions it here: http://lua-users.org/lists/lua-l/2009-11/msg00089.html
Tomblin: V8 still needs to check the hidden cl*** of each prototype in the prototype chain though. Caches do help but eh
Morine: I haven’t even read the papers on Self’s basic optimisations yet 😀
Lingelbach: The posts mike pall makes about luajit are usually very accessable
Poythress: Avoiding cache invalidation seems interesting
Drow: But the luajit source code is uh, a bit crazy tbh.
Cantin: I’d expect the code for most JIT optimisers to be pretty crazy
Tagliavia: Well the interpreter and the code generator are the same
Sadat: And are both generated by a custom ***embly preprocessor