Consider this benchmark: var s = new String(); for (var i = 0; i < 1000000; ++i) var q = g + "asdf"; Time, with empty loop time subtracted out: JM: 284 ms JSC: 153 ms TM: 34 ms TM is fast because it exposes and trace-compiles the defaultValue and valueOf calls. We should be able to achieve this effect in JM with a PIC-like technique at add sites that see string inputs. We think this will help xparb a bit. We don't know of other things it helps with yet, although it seems worth doing someday since the tracer does it. JM wanted SS win: 3 ms
A couple things I forgot: 1. This was spun off from bug 578257 comment 1, thanks to Alan. 2. For this particular bug, what we want is more of a special case in |add| to unwrap string objects rather than a general defaultValue/toString optimization.
Maybe I'm missing something here, but I'm assuming that the loop should be appending "asdf" to s, not g? Assuming that to be the case, I get the following: Interp: 299 TM: 315 JM: 98 JM+TI: 129 d8: 26 JM appears to be faster than it used to be, but still a long way from what TM used to be and d8 still is. Also worth noting is that TI regressed this by about 32%.
New numbers from my rMBP@2.7Ghz: SM: 52 d8: 9 jsc: 71
Summary: JM: Make |new String() + "asdf"| fast → IonMonkey: |new String() + "asdf"| 5.8x as slow as in v8
Still valid. Nightly - 85ms Chrome 45 - 32ms
It seems performance regressed on this microbenchmark. Firefox 50 - 206 ms Chrome 54 - 17 ms
You need to log in before you can comment on or make changes to this bug.