FakeString was introduced to avoid the XPCOM string ctors/dtors cost. But nsStringRepr has been added since then that has virtually the same ctors/dtors as FakeString. It would be better to derive it from nsStringRepr than to keep syncing the structure layout manually.

Hm, FakeString used to deliberately leave mData and mLength uninitialized, but bug 1406820 added th "missing" member initialization. Is this OK?

Well, I don't know. Did the relevant microbenchmarks get rerun when those initializations were added? That goes for NonNull as well, where we added extra initialization that didn't use to be there.... To be clear, those initializations weren't "missing"; they were left out because they were not needed and all that code is extremely performance-sensitive.

Yeah, guessing we got overzealous on compiler warning reduction. I'll remove the initialization and add comments.

Hmm, yes, I should have looked a bit deeper and skipped those parts of the flyby "fix". Or rather, I should have added the missing comments to those members to explicitly state that they're deliberately left uninitialized because the code is perf sensitive and what invariants make it safe to do that...

Thank you for the response. Then this bug is WONTFIX because FakeString would be still lighter than nsStringRepr.

Followup filed in bug 1428229.