ParseInt isn't a particularly good way to round a number to an integer.
Consider
parseInt(1e39)
parseInt(1000000000000000000000)
parseInt(0.0000000001)
Which all get the wrong answer. Math.floor will get these right,
though Math.floor("0x123") will interpret the number as a hex number
which may not be what you want. parseInt with an explicit radix will
return 0 for that string.
22. feb. 2011 07.39 skrev Ojan Vafai <[email protected]>:
> Great! It's anecdotal but, parseInt(x, 10), parseInt(x) and Number(x) are by
> far the most common forms I've seen in the wild.
>
> On Tue, Feb 22, 2011 at 5:25 PM, Anders Sandholm <[email protected]>
> wrote:
>>
>> Yes, I have a CL for parseInt. Just checking that there are no
>> regressions.
>> Will look into Number today CET.
>> -Anders
>>
>> On Tue, Feb 22, 2011 at 04:36, Ojan Vafai <[email protected]> wrote:
>>>
>>> Is it not possible to apply similar optimizations for parseInt(..., 10)?
>>> I don't think the conversion methods below are common knowledge and parseInt
>>> is usually given the radix (e.g. Google's JS style guide requires it). If it
>>> just optimized parseInt(x) and parseInt(x, 10), I think that would cover the
>>> vast majority of uses.
>>> While we're on this subject, how does Number(x) compare?
>>>
>>> Ojan
>>> On Mon, Feb 21, 2011 at 9:20 PM, Florian Schneider
>>> <[email protected]> wrote:
>>>>
>>>> Math.floor should work fine - in general you can make use of the
>>>> implicit conversions of Javascript operations: Two additional options that
>>>> may be even faster come to my mind: bitwise-or and unary plus. Bitwise-or
>>>> converts its input to integer-32, unary plus converts to a number.
>>>> Depending
>>>> on what the result should be, the most efficient ways with V8 to ensure
>>>> that
>>>> something is always a number (or an integer) would be:
>>>> y = x | 0 // y is always int32
>>>> y = +x // y is always a number (floating point or int)
>>>> or as already suggested by Mads:
>>>> y = Math.floor(x) // y is always an integer (possibly larger than
>>>> int32-range)
>>>> --Florian
>>>>
>>>> Den 21. feb. 2011 00.57 skrev [email protected]
>>>> <[email protected]>:
>>>>>
>>>>> I'm currently building a language for writing games that compiles
>>>>> directly to JavaScript. As a part of this I wrap JS arrays inside my
>>>>> own Array object, and inside it's 'set' method I run 'parseInt' on the
>>>>> given key to ensure the index is always an int.
>>>>>
>>>>> Due to warnings given by the closure JavaScript optimizer I use, today
>>>>> I changed 'parseInt( key )' to 'parseInt( key, 10 )' (the optimizer
>>>>> gives you a warning if you fail to do this). However I found that
>>>>> after adding the radix I received a major performance drop. I'm using
>>>>> Chrome 11.0.672.2.
>>>>>
>>>>> With some of the array intensive examples (namely this one
>>>>> http://playmycode.com/play/game/Sandbox/Blobs) the loss in framerate
>>>>> was almost 60% (from around 35fps on my machine to 15fps)! That's
>>>>> surprising since it's also doing lots of drawing too (although most
>>>>> time is spent on the number crunching). Simply removing the redux from
>>>>> parseInt solved this issue and brought the performance back up.
>>>>>
>>>>> In my own primitive benchmarks (running parseInt 1000's of times) I
>>>>> find similar, but with less of a performance drop. I'm just really
>>>>> stunned that simply supplying the radix can cause such a big drop in
>>>>> performance. Could this be solved in the future?
>>>>>
>>>>> --
>>>>> v8-dev mailing list
>>>>> [email protected]
>>>>> http://groups.google.com/group/v8-dev
>>>>
>>>> --
>>>> v8-dev mailing list
>>>> [email protected]
>>>> http://groups.google.com/group/v8-dev
>>>
>>> --
>>> v8-dev mailing list
>>> [email protected]
>>> http://groups.google.com/group/v8-dev
>>
>>
>> --
>> Anders Thorhauge Sandholm
>> Product Manager
>>
>> Google Denmark ApS | CVR nr. 28 86 69 84 |
>> Frederiksborggade 20B, 1 sal | 1360 Copenhagen K | Denmark
>>
>
> --
> v8-dev mailing list
> [email protected]
> http://groups.google.com/group/v8-dev
--
Erik Corry, Software Engineer
Google Denmark ApS - Frederiksborggade 20B, 1 sal,
1360 København K - Denmark - CVR nr. 28 86 69 84
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
