Make the microbenchmark below faster. The competition still runs this more than 2x faster than we do. This seems to account for a little over half the gap on date-format-xparb, and possibly more time in other benchmarks. function getS() { return 'a'; } function f() { return 8 + ',' + ' ' + 77 + ' ' + 33 + ',' + ' ' + 22 + ' ' + 12 + ':' + 46 + ':' + 45 + ' ' + getS(); }; var t0 = new Date; for (i = 0; i < 400000; ++i) { f(); } print(new Date - t0);

I thought we preconcatenated stuff like that at compile-time. Or do we only do that if it's all constant strings? Does date-format-xparb really have constant numbers being concatenated like that?

(In reply to comment #1) > I thought we preconcatenated stuff like that at compile-time. Or do we only do > that if it's all constant strings? Does date-format-xparb really have constant > numbers being concatenated like that? Clarification: the ints in the microbenchmark above correspond to function call exprs in the real date-format-xparb that return a number or a string. I confirmed that the perf difference is the same either way, so I simplified the benchmark. That said, it appears we don't preprocess the ' ' + ',' pairs in the middle. I don't know whether we can do so without altering semantics, but if so, it could be useful. I would estimate a 1 ms or so win from that in our current state, but much less if concatenation were faster generally. I could see it helping text-generating stuff on the web, though.

The general guts of the fix but there seems to be some bug I'm introducing that causes me to run into an assert.

Baseline landed. No more JM optimization work.

Well, wait. Do we not want an equivalent speedup for ion or bc? Or are we good here now?