parseFloat 与 parseFloat 相比有多快? JavaScript 中的浮点数?

发布于 2024-11-24 20:02:42 字数 368 浏览 1 评论 0原文

我从客户端的内部 API 获取了巨大的数据集。它将包含一堆价格数字数据,例如:31.23 美元。他将它们作为 {"spend":"21.23"} 提供给我,这很好,但我担心在 1000 多个项目并在所有项目上运行 parseFloat()这些值(除了绘制它们之外)可能会占用客户端浏览器的大量资源。

有人这样做过吗?

==更新==

抱歉。我的问题太模糊了。我担心的是它是一个字符串并且我正在解析它。我的问题是 parseFloat 比 int 更快。即,将 parseFloat("12.12") 附加到 div 比简单地附加 12.12 更快,如果是这样,快了多少。

I'm getting a huge dataset from a client's internal API. It'll contain a bunch of numerical data of prices such as: $31.23. He gives them to me as {"spend":"21.23"} which is fine, but I was concerned that after 1000+ items and running parseFloat() on all of those values (on top of graphing them) might be resource heavy on the client's browser.

Has anyone done this?

==Update==

I'm sorry. My question was too vague. My concern was that it's a string and i'm parsing it. My issue was is parseFloat faster than just an int. I.e. is appending parseFloat("12.12") to a div faster than simply just appending 12.12 and if so, how much faster.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

ペ泪落弦音 2024-12-01 20:02:42

在我的工作机器(Mac OS X、Intel 2 GHz Core i7)上,我在jsperf.com 上看到了以下结果

Browser    | parseFloat calls per second
----------------------------------------
Chrome 12  | 5.3 million
Firefox 6  | 21.7 million
IE 8       | 666.9 thousand <- totally unfair, ran on virtual machine
Opera 11   | 5.2 million

这远非详尽的调查;但如果每秒至少超过 60 万次调用(在虚拟机上至少),我认为您应该表现良好。

On my work machine (Mac OS X, Intel 2 GHz Core i7), I saw the following results on jsperf.com:

Browser    | parseFloat calls per second
----------------------------------------
Chrome 12  | 5.3 million
Firefox 6  | 21.7 million
IE 8       | 666.9 thousand <- totally unfair, ran on virtual machine
Opera 11   | 5.2 million

This is far from an exhaustive survey; but at a rough minimum of over 600 thousand calls per second (and that on a virtual machine), I think you should be good.

浅笑依然 2024-12-01 20:02:42

关于 parseFloat 或 parseInt 的速度 MDN 建议使用一元运算符 + 代替,如

+"12.12"
=> 12.12    

MDN 链接

一元加运算符位于其操作数之前并计算其操作数,但尝试将其转换为数字(如果尚未转换为数字)。尽管一元否定 (-) 也可以转换非数字,但一元加是将某些内容转换为数字的最快且首选的方式,因为它不对数字执行任何其他操作。

In regard for speed of parseFloat or parseInt MDN recommends using the unary operator + instead, as in

+"12.12"
=> 12.12    

MDN Link

The unary plus operator precedes its operand and evaluates to its operand but attempts to converts it into a number, if it isn't already. Although unary negation (-) also can convert non-numbers, unary plus is the fastest and preferred way of converting something into a number, because it does not perform any other operations on the number.

非要怀念 2024-12-01 20:02:42

您知道 parseFloat() 是基于浏览器的。据我所知,浏览器可能会在 200 个值后崩溃,在 10.000 个值后可以正常工作。

这取决于浏览器有多少个选项卡、正在运行哪些其他脚本、有多少 CPU 可用于处理,当然还有什么浏览器,

如果您的客户端使用带有 1000 个插件的 Firefox,它将永远无法顺利运行您的脚本。

只是我的意见。如果你想做得更好,你应该在服务器上进行预处理然后显示。

you know that parseFloat() is based on the browser. So as far as I know the browser could crash after 200 values, could work just fine after 10.000 value.

It depends on how many tabs that browser has, what other scripts is running, how much CPU is free for processing, and of course what browser

if your client uses firefox with 1000 addons it will never run your script smoothly.

just my opinion. If you want to do it nice you should preprocess on a server then display.

明媚殇 2024-12-01 20:02:42

输入

javascript:a = +new Date; x = 100000; while (--x) parseFloat("21.23");警报(+新日期 - a);

进入你的网址栏。

这是唯一可以确定的方法。

老实说,你无法回答这个问题。这取决于浏览器,例如firefox 8应该比6更快,等等。

Type

javascript:a = +new Date; x = 100000; while (--x) parseFloat("21.23"); alert(+new Date - a);

Into your url bar.

This is the only way to know for sure.

In honesty, you can't answer the question. It depends on the browser, for example, firefox 8 should be faster than 6, and so on.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文