On Wed, Mar 15, 2017 at 6:33 PM, Alex Harui <aha...@adobe.com> wrote:
> Here's a better link to the old thread. Looks like I did mess around with > parseInt earlier. > > https://s.apache.org/rHq2 > > > The goal is to match what AS does and get the performance benefit you > measured and maybe prevent browsers from doing something strange. > > Hopefully it won't require sniffing the first parameter ourselves. > > Thanks, > -Alex > > > Thanks for that link, the original was not working for me. In theory it should simply take the string and deduce the radix internally depending on whether the string has '0x' at the start or not. That's why specifying the radix should always be faster. But we cannot assume it is 10 for all strings in a compiler generated version with the (apparently) mandatory second param for GCL. So it is a bit of challenge if we want to keep the AS behaviour, and if the GCL lib does not like having the second arg missing. Basically for perfomance you need to specify the second param in the native version and that obviously will always be the better option. I think the compiler generated version will need to do some sniffing unfortunately, (if we are to keep behaviour) and will make that performance difference even more true, but will give it a bit more thought. .
