Bug 167119
| Summary: | [JSC] Handle parseInt in DFG / FTL for kraken crypto-ccm | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Yusuke Suzuki <ysuzuki> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | saam |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Yusuke Suzuki
kraken crypto-ccm repeatedly calls parseInt function.
I think we have a chance to optimize it by handling it in DFG, because
1. typically the second `radix` parameter is constant! We typically call it in the form like `parseInt(xxx, 10)`. So in that case, many checks can be dropped.
2. typically the first parameter is string. We can use StringUse to avoid string type check & conversions in parseInt function.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Saam Barati
(In reply to comment #0)
> kraken crypto-ccm repeatedly calls parseInt function.
> I think we have a chance to optimize it by handling it in DFG, because
>
> 1. typically the second `radix` parameter is constant! We typically call it
> in the form like `parseInt(xxx, 10)`. So in that case, many checks can be
> dropped.
> 2. typically the first parameter is string. We can use StringUse to avoid
> string type check & conversions in parseInt function.
I was looking at this too last Friday!
Some more details, for Kraken specifically:
- Radix is always (almost) the number 16
- String is always a rope (I think a substring style rope)
Saam Barati
I was also thinking that making String.prototype.substr an intrinsic could help performance on some kraken tests.