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
