See url; TM is about 20x faster than JM here. V8 tip is about 6x faster than JM. I assume that it's not worth worrying about this too much until we fix bug 639099.

Looks like JM+TI wipes the floor with v8 now. JM+TI v8 Plus 1 421,492,702 ±1.91% 97,673,014 ±10.51% PlusPlus 199,961,322 ±8.24% 97,673,014 ±10.51% Plus Variable 199,961,322 ±8.24% 52,415,202 ±7.63%

Why are we slower with PlusPlus than with Plus 1?

I made a shell testcase, and assuming I did things right, I get some interesting results. All numbers are iterations/ms (higher is better). The TM numbers are from the 2011-10-01 nightly. Interp: TM: JM: JM+TI: d8: Plus 1 4946 243902 97087 277778 52356 PlusPlus 6502 312500 69930 277778 50000 Plus Variable 4211 243902 64935 263158 45872 bz, does this shell testcase look legit or did I do something silly? Overall, the performance delta between JM+TI and v8 is on the same order of magnitude, but you see generally pretty equivalent numbers between the tests for each engine. Also worth noting is that TM was the fastest engine on PlusPlus.

I _think_ the original jsperf test would correspond to your shell testcase but without the "a = 0" sets after the first line. And also, with each loop wrapped in a new Function(). Looking at the jsperf test on my machine, for example, when the test is all done I see a == 4,436,749,015 Which means that chances are, a+=1 in the jsperf test is running on integers but by the time you get to a++ and a+=b we've overflowed to doubles. Which may be the answer to comment 2, incidentally.

Well, that's kind of silly. Hard to compare x to y to z if you aren't given each the same starting conditions. Anyway, I made the changes you talked about and tested it with 10,000,000 iterations (should stay as an int) and 2,500,000,000 iterations (overflow to a double). 10,000,000 iterations Interp TM JM JM+TI d8 Plus 1 6414 250000 112360 370370 263158 PlusPlus 12180 370370 111111 333333 263158 Plus Variable 5528 250000 98039 370370 238095 2,500,000,000 iterations Interp TM JM JM+TI d8 Plus 1 5839 239212 84314 218780 85441 PlusPlus 2837 254479 79580 187392 117874 Plus Variable 4731 252194 62293 202626 104677 Looks like forcing an overflow definitely has an effect. However, I still don't see the 2x dropoff like comment #2. And TM seems to be the best performer.

> Hard to compare x to y to z if you aren't given each the same starting conditions. Par for the course for jsperf tests; resetting the initial conditions between tests there is rocket science for most jsperf users. > However, I still don't see the 2x dropoff like comment #2. You see a dropoff from 370370 (without overflow) to 187392 (with overflow). That seems pretty close to 2x to me. > And TM seems to be the best performer. Yeah, this is just about a best-case scenario for TM. IM should hopefully do well here too.

I meant a 2x dropoff from Plus 1 to PlusPlus in the same test run. I guess I was expecting to see the Plus 1 numbers to be about the same whether 10,000,000 iterations or 2,500,000,000 iterations with the dropoff occurring on PlusPlus. Otherwise, yes, the numbers are basically in the same ballpark as the browser. I'm going to be looking to add this test to awfy-assorted. If it sounds good to you, I'd like to check in a version that resets a to 0 between tests but has them in separate functions like the attached. However, I get different results with this version too. It seems that JM+TI actually speeds up a bit. Interp TM JM JM+TI d8 Plus 1 6250 232558 117647 434783 256410 PlusPlus 12500 370370 106383 370370 263158 Plus Variable 5402 243902 92593 370370 238095

> I guess I was expecting to see the Plus 1 numbers to be about the same whether 10,000,000 > iterations or 2,500,000,000 iterations with the dropoff occurring on PlusPlus. Our internal integer representation here is signed 32-bit, so overflow first happens around 2,000,000,000. So the "Plus 1" test was already hitting overflow in your test. Adding a sane version of this to awfy-assorted sounds fine.