[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