其实做过相关测试的博客已经不少了, 但不自己亲身试一下, 死不了这条心. 所以今天恰逢周六,
来用测评笔记本的思维测评一下两者的性能对比.(本人喜欢在51论坛发博客, 此论坛是一个笔记本分享体验的论坛).
关于这件事情, 大多数人测得结果是原生for性能要好于map, 事实真的是这样吗? 看完此篇, 相信你能找到答案.废话不多说, 现在开始:
测试方法:
1. 创建一个数组, 内有33333333项, 然后开始循环并记录时间, 循环结束后输出所耗时长.
2. 每种方式记录3次时间, 最后算出平均所用时长.
测试说明: 1. 为了确保测试严谨, 考虑到此次只针对循环性能进行测试, 所以创建数组的耗时不在统计范围之内.
2. 考虑到笔记本长时负载cpu有降频的可能性, 所以不采取耗时过长的测试方法. 当然, 测试也不宜过短,
否则无法说明问题.cpu的PL1一般都设定在28s.所以只要不超过28s就没问题. 且单项测试完会让机器恢复到正常温度.
避免高温降频导致的误差.且每次采用打开浏览器的方式, 不采用刷新网页的方式.
3. 因一种数据类型无法说明问题, 所以分别测试数组内的项为number, string, object的情况所需时长.
4. 我的机器配置: 型号: 戴尔Precision M5520. cpu: i5 7440hq. 具体参数为: kabylake架构, 四核四线程,
单核睿频3.8ghz, 四核睿频3.4ghz. tdp45w.
测试代码如下:
let test = 99999; // number
let test = 'abcde'; // string
let test = {test1: "测试中1", test2: "测试中2", test3: "测试中3"}; // object
let arr = new Array(33333333).fill(test);
console.time();
// 原生for
for (let i = 0; i < arr.length; i++) {
}
// map
arr.map((item, index, arr) => {
})
console.timeEnd();
我会分别测试以上三种数据类型, 分别测试3次记录时间, 分别用for, map两种方法测试.
实测结果如下:
原生for循环 map循环
第一次: 459.515625ms 1214.30712890625ms
number 第二次: 457.640869140625ms 1219.38623046875ms
第三次: 466.174072265625ms 1212.14892578125ms
第一次: 455.422119140625ms 1316.40087890625ms
string 第二次: 450.8349609375ms 1315.333251953125ms
第三次: 458.367919921875ms 1308.587158203125ms
第一次: 460.298095703125ms 2399.734130859375ms
object 第二次: 464.030029296875ms 2425.638916015625ms
第三次: 456.2041015625ms 2415.697021484375ms
结论:
1. map和原生for循环确实存在性能差异, for比map快2倍到5倍不等.(仅在此次测试中), 而且, 数据越复杂, 两者性能差距越明显.
2. 把map的参数去掉时间也是不变的.
3. 原本计划计算出平均耗时, 其实目前我是一边测试一边记录, 也算半个直播了. 但是测试结果差异太小了, 口算也能算出平均值了. 所以平均值就不计算了.
总结:
1. object项足足有五倍的耗时差距. 是不是有点儿惊讶? 是不是以后打算用map写代码了? 别着急, 且听细细道来.
2. 首先, 工作中, 并不会出现要循环这么庞大的数据(好吧, 万万一你有, 像object这种直接耗时差将近2s, 那确实2s很奢侈了, 是必须采用for).
一般工作中大多数情况下循环的时长都不超过1ms(不包括循环内数据操作). 所以, 纠结这点儿性能完全没必要.
3. map循环的便捷性, 可维护性. 是for远远不能比的. 本人愚见: 离开可维护性, 便捷性只谈性能难道不是耍流氓吗? 而且我们写代码也是为了实现需求,
在实现需求的基础上再谈优化性能.
4. 如果要分析原因的话, 请恕我才疏学浅, 无法下结论.
5. 闲来无事, 只为满足自己的兴趣. 大家全当时耍子. 如有任何不足之处, 还望批评指正, 感谢!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。