- 主题:js的速度优化
google developers里说,直接拼字符串比用数组join慢,但是我实际写了段代码,发现数组join更慢,这是为什么?
--
FROM 117.184.104.*
贴代码
【 在 zeus2615 (zeuslord·呆猫) 的大作中提到: 】
: google developers里说,直接拼字符串比用数组join慢,但是我实际写了段代码,
发现数组join更慢,这是为什么?
--
FROM 66.162.88.*
多半是你写错了。原生api比较简单的+一定快
--
FROM 123.125.212.*
非常同意
【 在 LukasLi (笨笨熊) 的大作中提到: 】
: 多半是你写错了。原生api比较简单的+一定快
--
FROM 111.204.252.*
因为 google developers错了。
直接拼字符串:
1)string是primitive type, which is simple
2)对string的+可以静态 优化掉
数组join需要:
1)动态执行
2)对对象进行操作,还要考虑每个属性值是什么类型
【 在 zeus2615 (zeuslord·呆猫) 的大作中提到: 】
: google developers里说,直接拼字符串比用数组join慢,但是我实际写了段代码,发现数组join更慢,这是为什么?
--
修改:ottffsse FROM 183.95.135.*
FROM 183.95.135.*
【 在 ottffsse 的大作中提到: 】
: 因为 google developers错了。
: 直接拼字符串:
: 1)string是primitive type, which is simple
: ...................
旧的浏览器是join块,因为string拼接没有做过优化
新浏览器必定string拼接快
--
FROM 106.37.179.*
这可不一定,这取决于实现。大量字符串拼接时,join 可以先把结果串的长度算出来才开始拷内容,避免反复重新分配内存。
当然现在 js 通常是直接用加号更快了。而 Python 至今仍然是 join 比加快。
Browser string optimizations have changed the string concatenation picture.
Firefox was the first browser to optimize string concatenation. Beginning with version 1.0, the array technique is actually slower than using the plus operator in all cases. Other browsers have also optimized string concatenation, so Safari, Opera, Chrome, and Internet Explorer 8 also show better performance using the plus operator. Internet Explorer prior to version 8 didn’t have such an optimization, and so the array technique is always faster than the plus operator.
【 在 ottffsse (nothing) 的大作中提到: 】
: 因为 google developers错了。
: 直接拼字符串:
: 1)string是primitive type, which is simple
: ...................
--
修改:vonNeumann FROM 211.99.222.*
FROM 211.99.222.*
谢谢冯大师解释
【 在 vonNeumann (劣币驱逐良币 | Busy) 的大作中提到: 】
: 这可不一定,这取决于实现。大量字符串拼接时,join 可以先把结果串的长度算出来才开始拷内容,避免反复重新分配内存。
: 当然现在 js 通常是直接用加号更快了。而 Python 至今仍然是 join 比加快。
: Browser string optimizations have changed the string concatenation picture.
: ...................
--
FROM 222.67.43.*
["a","b", , "c"].join() 相当于
一个Array实例的方法调用,首先要检查这个对象有没有这个方法,然后join方法要调用第0到第n-1个属性值的toString(),还要考虑被删掉或省略掉的0-(n-1)属性,怎么快呢?
join如果把结果串的长度计算出来,是不是假设数组元素都是string类型的,还是调用toString之后算出来的?
当然,如果运行环境对string数组的join做了特别的实现,那另就是想让哪个快就让哪个快,即使快不了,我也可以让另一个慢下来,没什么意义。
而+对string的操作属于简单类型的操作符,+是标准定义好的,join的优化完全可以用在join上;如果运行环境把这个弄得不快只能说环境有点奇怪。
【 在 vonNeumann (劣币驱逐良币 | Busy) 的大作中提到: 】
: 这可不一定,这取决于实现。大量字符串拼接时,join 可以先把结果串的长度算出来才开始拷内容,避免反复重新分配内存。
: 当然现在 js 通常是直接用加号更快了。而 Python 至今仍然是 join 比加快。
: Browser string optimizations have changed the string concatenation picture.
: ...................
--
修改:ottffsse FROM 183.95.135.*
FROM 183.95.135.*
http://jsperf.com/array-join-vs-string-connect大家跑这个试试呢?
我的chromium用+快很多
【 在 ottffsse (nothing) 的大作中提到: 】
: ["a","b", , "c"].join() 相当于
: 一个Array实例的方法调用,首先要检查这个对象有没有这个方法,然后join方法要调用第0到第n-1个属性值的toString(),还要考虑被删掉或省略掉的0-(n-1)属性,怎么快呢?
: join如果把结果串的长度计算出来,是不是假设数组元素都是string类型的,还是调用toString之后算出来的?
: ...................
--
FROM 222.67.43.*