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.
(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)
I was also thinking that making String.prototype.substr an intrinsic could help performance on some kraken tests.