On 20.12.2010 20:44, Lasse Reichstein wrote:
On Mon, 20 Dec 2010 09:24:12 +0100, Dmitry A. Soshnikov
<dmitry.soshni...@gmail.com> wrote:
On 20.12.2010 1:16, Lasse Reichstein wrote:
[Mutalbe __proto__]
It's there now, so performance won't be any worse than today.
Personally, I think the cost of a mutable prototype is subsumed in
the cost of having mutable objects in the prototype chai. You still
have to check the entire prototype chain every time you make a lookup.
Can you clarify? You mean an optimization (sort of inline caching?)
which can be made on non-rebinding [[Prototype]]?
Not sure I understand the question.
Sorry, my confusion. I meant exactly an optimization with inline-caching
and was thinking about how immutable (with an ability to rebind)
[[Prototype]] may help.
What I'm saying is that an optimizing property lookup, e.g., using
inline caching,
will need to check the prototype chain for changes in any case if the
property
is inherited.
Yeah, the application of an inline caching in JS seems is very unstable.
I.e. it can be implemented for only "clear" object (and which usually
are created by the built-in constructors).
For example, I can assume that in the following example the
(monomorphic) cache can be used:
"1".toString
since at first glance the (intermediate) object will always use the same
resolved method (and therefore the call-site can be cached inline).
However, it's only on the first glance, since again after each such a
line the position of `toSting` (and the `toString` itself if it stays in
the same position) in the prototype chain can be repeatedly changed.
Moreover, the penalty with constantly creating an intermediate object
also may cancel this caching.
It's even harder to provide such a caching for an object with the same
[[Class]] "Number", because this object may have always different
prototype chain and the `toString` method may appear on the different
link of the chain. I.e. inline caching isn't relate with just checking
the type/class/constructor in JS.
Of course, if there is a mechanism of invalidating of the cache (e.g. by
changing the `toString` method of on the `Number.prototype`) then again
some _static_ code with creating a Number object may use the inline
cache (regardless that the property is inherited):
var a = new Number(1);
a.toString(); // monomorphic cache
But I'm not aware how hard to implement such an invalidation (what if
not the toString will be changed, but instead another toString is added
on the nearer link of the prototype chain? -- obviously it should be
invalidated).
All other cases seems are non-cacheable and, in general case -- none of
the cases. So, yeah, I also think that mutable __proto__ won't bring
additional performance issues, since anyway a dynamic lookup in general
case is required.
If it's not inherited, but is an "own property", you don't need to
check the prototype chain in either case. I.e., it makes no difference
whether
mutable __proto__ exists, you need to check the prototype chain in the
same way
whether the prototype chain changes or it's just the properties on the
objects that
do, so I doubt that a settable prototype will change the performance
of property
lookups.
Indeed.
However, if you don't have a mutable [[Prototype]] property, there are
a few
other optimizations that become possible, e.g., caching "instanceof"
results, since
they depend on the shape of the prototype chain only, not the
properties of the
objects. That might be the performance issue that TC-39 was thinking of.
Yep, a good case, but I'm not sure it's a very important case to avoid
an elegance and a shortness of the code description. As mentioned TC-39
also doesn't like the old-school (?) idea with non-stratified meta- and
normal- levels. Though, I don't know how much it's a bad idea. On one
hand it allows to describe objects clearer and easier (without those
longLinesOfJavaStyleCode which is chosen) on the other hand, the
stratification may be really a good idea.
Dmitry.
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
