Self-host Object.prototype.toString

RESOLVED WONTFIX

Status

()

enhancement
RESOLVED WONTFIX
2 years ago
2 years ago

People

(Reporter: jandem, Unassigned)

Tracking

(Blocks 3 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
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.
(Reporter)

Comment 1

2 years ago
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 :(
(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.
(Reporter)

Comment 3

2 years ago
(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.
Whiteboard: [qf:p1]
(Reporter)

Comment 4

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

Updated

2 years ago
No longer blocks: TimeToFirstPaint_FB
(Reporter)

Comment 5

2 years ago
Bug 1369042 optimizes the @@toStringTag lookup, it makes this one less urgent.
(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.
Flags: needinfo?(jdemooij)
(Reporter)

Comment 7

2 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(jdemooij)
Resolution: --- → WONTFIX
Whiteboard: [qf:p1]
You need to log in before you can comment on or make changes to this bug.