After the specific optimization in bug 591172, i collected some ideas from irc. #1 Currently bug 591172 only handles typeof x === 'number', in exact this order, this should work in reverse too. #2 Possibly we could emit specific code for "object" and "function". #3 Somehow we could inline the whole typeof. #4 Optimize the LOOKUPSWITCH >> switch(typeof x) we either could check if there are only cases, which we are able to handle (string, number, undefined, boolean), and then rewrite it to an TABLESWITCH, with type as the condition. This might not be needed if we could always inline typeof. There is two related bugs, bug 470143 |typeof nosuchvar| is nearly as slow as the inpreter bug 606648 |typeof x[outofbound]| is slow too
#1 seems most easily doable as a parser modification -- just create trees with the canonical ordering that optimizing passes will recognize. (Or, more accurately, munge parsed trees in a post-creation pass, the same way we fold constants and all that.) You have to have the literal type-string to do this, so maybe you lose out on variable-but-constant typeof optimizations, but I don't know if we do those, and I suspect the win from them if we did do them isn't nearly as large as the compare-to-literal case.
Summary: Future Optimize 'typeof' → Further Optimize 'typeof'
We are probably not going to fix this in JM. And we have more-or-less the same bug for ion: Bug 725966.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.