Perfherder has detected a talos performance regression from push a2664bf7445fdaf1365f4cd53655318646006a46. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) may be backed out in accordance with our regression policy.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

For more information on performance sheriffing please see our FAQ.

Set release status flags based on info from the regressing bug 1785942

This was unexpected. It could be the result of an inlining difference or something. I will look into it.

This appears to be the result of the final of the 8 patches. It's the one that switched all of the JSStrings over to placement new.

I'll try to break it down further.

I fully expected that I had botched something in the new atom allocation path, since that's by far the biggest set of changes, but that turns out to be performance neutral. There are 3 categories of strings whose allocation is affected: atoms, inline strings, and all other strings. Only the inline strings make a difference. And it seems to be Windows-only, more or less. (The alert has one result for OSX, but looking at the graph, it's hard to tell if it's real.) It also only shows up on the one set of related tests.

I looked at the generated code on Linux, and they're doing pretty much the same thing. (I was worried I might be double-initializing or something.) But Linux doesn't show a perf difference, so it could somehow be a Windows-specific compilation difference???

Sprinkling around more MOZ_ALWAYS_INLINE didn't help.

:sfink any updates on your investigation from comment 5?

Too late for 107.
Leaving 108 clear, unless there's a follow-up planned?

Looking at the current graph, these tests are a bit unstable. They are bimodal, but the mode is persistent for long stretches. The current perfherder graph shows it dipping back to the faster speed twice since this patch landed. It is feeling unlikely to me that tweaking my patches until it falls back down to the faster mode is going to help anything; something else will pop it back up eventually.

It could be worth digging into why this is happening, but I would rather not do the digging myself.

To be clear, I'm not saying this is an invalid test result. It seems that the Windows executions of these tests really did get slower. I filed bug 1797845 for the instability.

I'm going to mark this WONTFIX, but I'm happy to have someone argue otherwise.