Closed Bug 883661 Opened 9 years ago Closed 9 years ago
Handle lazy functions in Fast
Currently, FastInvokeGuard is not able to use its Ion fast path if the called function is initially lazy. This causes a sort() operation in ss-string-tagcloud to take twice as long when using lazy parsing, and slow the benchmark down by about 20%. The attached patch fixes this, and also fixes a similar issue when pattern matching numeric comparators during sorts. (The comparator used in tagcloud actually happens to be doing a numeric sort, but the pattern matching isn't able to catch this.) With this fix, string-tagcloud takes about the same with vs. without lazy parsing.
Attachment #763268 - Flags: review?(luke)
Looks like this regressed ecma/Array/18.104.22.168-3.js.
Blech, the enum values for ComparatorMatchResult were involved with some undocumented invariants. https://hg.mozilla.org/integration/mozilla-inbound/rev/ede58026dcb5
Ouch. Double ouch: it looks like there is a second instance of this: SortComparatorInt32. In push to fix the above, could you add a Match_COUNT and then JS_STATIC_ASSERT(Match_Count == JS_ARRAY_LENGTH(SortComparatorNumerics)) and also for SortComparatorInt32?
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.