1346546 - Self-host Object.prototype.toString

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, enhancement)

Description

[Jan de Mooij [:jandem]]

I noticed this in the Angular part of Speedometer this week. We spend a few % under obj_toString, especially the GetProperty call there for @@toStringTag, but also a few ms under StringBuffer::append to construct the "[object Foo]" string.

If we self-host this, the JITs can optimize the GetProp to be much faster and we can just use concatenation for the "[object Foo]" string (which should be faster than StringBuffer).

We may need some intrinsics for this, for instance to get an object's clasp->name, but we could inline that in Ion if we know the Class statically.

This will probably not be a measurable win on Speedometer, but it should still be a nice clean up and performance improvement.

Comment 1

[Jan de Mooij [:jandem]]

Note that we optimize some common cases to return atoms like "[object Array]". With the right intrinsic(s) we should be able to keep that behavior though.

A bigger issue here is probably OrdinaryToPrimitive, that will get very slow if we change it to call into JS :(

Comment 2

[Till Schneidereit [:till]]

(In reply to Jan de Mooij [:jandem] from comment #1)
> A bigger issue here is probably OrdinaryToPrimitive, that will get very slow
> if we change it to call into JS :(

We could keep the C++ version around and use that if we detect that we would call the self-hosted Object#toString.

Comment 3

[Jan de Mooij [:jandem]]

(In reply to Till Schneidereit [till] from comment #2)
> We could keep the C++ version around and use that if we detect that we would
> call the self-hosted Object#toString.

Yeah, that might also be faster than going through the native call mechanism like we do now.

I also think we should atomize these "[object Foo]" strings - we will currently allocate the same strings over and over again and I'd expect most of these atoms to be short-lived so they should be collected by the next GC.

Comment 4

[Jan de Mooij [:jandem]]

This also shows up on Dromaeo. For one of the subtests of traverse-prototype I see 24% under obj_toString.

Comment 5

[Jan de Mooij [:jandem]]

Bug 1369042 optimizes the @@toStringTag lookup, it makes this one less urgent.

Comment 6

[Alex Thayer [:alexical] (she/her)]

(In reply to Jan de Mooij [:jandem] from comment #5)
> Bug 1369042 optimizes the @@toStringTag lookup, it makes this one less
> urgent.

Is this still qf:p1 worthy? If it is, I'm interested in taking it.

Comment 7

[Jan de Mooij [:jandem]]

(In reply to Doug Thayer [:dthayer] from comment #6)
> Is this still qf:p1 worthy? If it is, I'm interested in taking it.

Since bug 1369042 the property lookup here is much faster and self-hosting would actually make us slower for polymorphic calls. There are still things we could optimize in obj_toString and we probably shouldn't self-host at this point.