On Tue, Feb 22, 2011 at 09:47, Erik Corry <[email protected]> wrote:
> 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.
>
In V8 r6879.
> >> 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
>
--
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
