In a lot of Widgets I see people use .state.split(' ')[0] to get rid of the unit used, but as far as I know the whole Number object is available, including Number.parseInt and Number.parseFloat - why aren’t these used more?
Same goes for Number() instead of a specific submethod like Number.parseInt() and Number.parseFloat()?
For me, it depends on the purpose. If I’m just displaying the value, the split is the better option because it is already a string and converting to a number and back is a lot of extra overhead. But, of course, if you’re going to do math or numerical comparison, then you need the conversation instead.
*See the note about categories in the other post.
I get the reasoning if it’s for display purposes - but I noticed one of the widget I got from the forums loading way better and performing better after I changed all state.split(' ')[0] for calculations to Number.parseFloat so there is a performance increase there.
Also, thanks for moving the post to the right category - mistakenly used the wrong one as I was looking at Widgets and couldn’t find a topic aimed at questions about them - note taken.
I’m a little surprised by that, I admit.
If the widget has enough of those calls to make a perceptible difference, however, then you probably even want to move to regex which should be significantly faster than both of those:
('123.456 unit').match(/[-\d.]*/)
I wonder what’s going on with the split case. As I had guessed, a quick and dirty benchmark test shows that split is a little faster than parseFloat (although regex beats them both).
Maybe that’s because parseFloat is actually the fastest? You made a little mistake in the benchmark - Number.parseFloat() returns the number itself - you shouldn’t use [0] on it:
Nope, you are misinterpreting the results. The numbers given are the number of operations completed in the the time frame, so the higher number is the faster operation. It even specifically says parseFloat is the slowest and is half as fast as regex:
The results were definitive enough that I wasn’t worried about too many small facotrs like that. If we really want to be as accurate as possible then we would also want to .toString() the parseFloat value to emulate displaying that value as a string which is the intention half the time with widget expression anyway:
Interestingly, that significantly hampers the regex speed, but the other two remain mostly the same, so parseFloat is still slower then split:
In the end, however, although this is all theoretically interesting, it is mostly moot. The widget exrpessions are NOT js they are a js-like expression parser so the speed of these operations has more to do with how they are implemented in the jse-eval library than raw js. If you say you see a performance boost with parseFloat in a widget, then that may be true.
You know what’s most weird - when I run your last benchmark, parseFloat is the fastest, I ran it three times to be sure:
Also, the reason I probably saw the improvement in the widget was because the only places which I changed where the comparisons and calculations with numbers - so where numbers where being compared etc
Just to extend on the above, I tried some other browsers and the differences are big!
Firefox (the one used above):
Microsoft Edge:
Google Chrome:
Interesting. I use Chrome so that makes the results consistent. I guess it’s not too surprising that the browser’s js engine has an impact (my 40+ chrome tabs, may play a role too 
).
Luckily everything is handled in the expression parser in the backend so it’s browser independent
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.
