Yes I'm parsing values that are probably numbers, but could be other things like strings. I had guessed that V8 might have been failing to optimize if the radix was supplied. I'd suspect with parseInt people would very often supply the radix as a constant, so perhaps this could be included in the future.
'x | 0' seems to be a tad faster then Math.floor, so I'll be using this. Thank you! On Feb 21, 10:20 am, 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
