[Webkit-unassigned] [Bug 153738] New: [JSC] Make array iteration methods faster

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Feb 1 02:57:52 PST 2016


https://bugs.webkit.org/show_bug.cgi?id=153738

            Bug ID: 153738
           Summary: [JSC] Make array iteration methods faster
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: utatane.tea at gmail.com

Seeing DFG dump, (unfortunately!) Array iteration methods (like forEach) performs Double Comparison on loop condition!
This is because,

1. Poor toInteger implementation

We should convert @Number(...) to NumberUse edge filtering. And implementing isFinite in JS is better (If value is speculated as Int32, we can purge many conditions!)
Like, (Number.isFinite)
function isFinite(value)
{
    return value === Infinity || value === -Infinity;
}
And, (global).isFinite
function isFinite(value)
{
    var numberValue = @Number(value);  // This should be converted to edge filtering.
    return numberValue === Infinity || numberValue === -Infinity;
}

Handling NumberConstructor::info() in DFGByteCodeParser.cpp makes it easy I think. And to ensure more high performance implementation, introducing @toNumber bytecode intrinsic (that emits to_number bytecode) may also be good.

2. maxSafeInteger = 0x1FFFFFFFFFFFFF

Now, in toLength, we have a chance to return maxSafeInteger (This is represented as double). It is unfortunate, because it makes the result value double rep.
One plan is,

When comparing value < maxSafeInteger, and if we know value is Int32, value < maxSafeInteger becomes always true.
So we can purge this comparison and maxSafeInteger. It makes the result value Int32.

How about this?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160201/085b2c0b/attachment-0001.html>


More information about the webkit-unassigned mailing list