Closed Bug 883661 Opened 10 years ago Closed 10 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/188.8.131.52-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: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.