6 ms·
Conversions in Javascript
- turshija 14y agoFirefox results are amazing, "wicked" is over 20x faster then any other method ...
- froball 14y agoWhy people are so keen on micro-optimizing their code? The bottleneck lies on DOM, not on your conversions.
- Herover 14y agoI guess that depends on what you are doing. If you have a 10k csv file and want to make a graph using javascript, I believe it could come handy.
- FuzzyDunlop 14y agoOne might prefer to supply the radix when using parseInt(), too. Lest one encounters strings that convert into octal numbers. parseInt('09') !== parseInt('9')
- Stratoscope 14y agoThis article has a few problems. * "All of the above does the same job...". Not true at all; the four examples do three very different things. Try them with a more interesting string argument, say '012.78': parseInt('012.78') // 10 (number interpreted as octal integer) Number('012.78') // 12.78 +'012.78' // 12.78 ~~(1*'012.78') // 12 * "...and n1==n2==n3==n4" Using == instead of === here makes the statement meaningless. After all, this is also true: '12' == 12 * The "wicked" method, ~~( 1 * '12' ), smacks of cargo cult programming. No mention of the fact that it uses two operators instead of one? Why not test the two separately: 1*'012.78' // 12.78 ~~'012.78' // 12 Complaints aside, the results for the "wicked" method certainly are interesting. Why is it (along with the two variations above) so extremely fast in Firefox? Here's an updated jsperf with those additional test cases: http://jsperf.com/parsenumber/5 http://jsperf.com/parsenumber/5
- cygx 14y agoIn general, using operators will speed things up as these can be statically dispatched. No idea why +'12' is so slow, though - 0+'12' doesn't suffer from this...
- some-1 14y ago-0+'12' (and 0+'12') doesn't convert it to a number, it converts the zero to a string and then concatenate them to the string "012". And Firefox optimize it: Function('return -0+"12"').toString(); Returns: "function anonymous() { return "012";}" So there is no conversion going on in the test, it just returns the string "012". No wonder that it is fast. See my comment above for another jsperf where it is converted in each test.
- cygx 14y agoDamn - too much Perl coding recently, where + is always arithmetic. However, my point still stands: Why are some operators (and in particular unary minus, which is probably the most commonly used one) so much slower than others?
- some-1 14y agoSee the following comment: http://news.ycombinator.com/item?id=4530557 http://news.ycombinator.com/item?id=4530557 The reason why some of them is so fast is because the constant expression is evaluated to a constant, so instead of doing a conversion in the test, the already converted number is returned. Use this test instead: http://jsperf.com/parse-number-from-string http://jsperf.com/parse-number-from-string
- Stratoscope 14y agoOther folks have jumped in and improved those tests. It's up to revision 10 now: http://jsperf.com/parsenumber/10 http://jsperf.com/parsenumber/10 (scroll down the page to find any newer revisions)
- some-1 14y ago
- cygx 14y agoExcept for n2 and n3, all of these have different semantics. Performance doesn't help if your code is wrong.