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.
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.
(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.
This also shows up on Dromaeo. For one of the subtests of traverse-prototype I see 24% under obj_toString.
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.
(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
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.