猜测是 map，考虑性能干嘛用 ruby。我准备滚回 java 和 erlang。

🙋 研究过的是不是只要举手就可以了？

Fast Ruby: https://github.com/JuanitoFatas/fast-ruby Erik Michaels-Ober - Writing fast Ruby

都一样很快

#4 楼 @ywencn 你确定吗？数组基数有多大？

#4 楼 @ywencn 其实我觉得你的意思应该是都一样慢:)

你说的就是 merge 与 merge! 的差别吗？

这不是技术实用主义，这是技术虚无主义……进入到ruby这个领域就没有遇到过什么太多太深的问题 说明应该换个环境了。

楼主的性格适合做个人站长，不适合跟“极客”一起吹逼，见我这贴 https://ruby-china.org/topics/28321 ，现在还有用 windows 2003 + iis + php + ftp 上传，一样赚的风生水起的。

#5 楼 @crazyjin 首先，性能是绑定到版本的。 MRI 与 JRuby 性能就不一样，Ruby1.8 与 Ruby2.2 又可能会不一样。

然后，map 和 map! 之间就差一个 replace 吧，这么说 map! 会慢 0.0000x 秒。

另外这并不是什么技术问题。 首先这可以通过源代码分析；其次追求性能应该用汇编写。 用 Ruby 写代码，就是为了把这些无所谓的性能问题扔到一边去。

Premature optimization is the root of all evil.

说实话，这个问题我也没有去做过

但是如果这是面试题，我想正确应该答案是：

我没有试过 map 和 map! 的性能问题，因为我觉得这两个性能差别应该不会太大，但是我对 Ruby 应用的性能问题很关注，但我觉得这样的测试只要关注别人的测试结果就足够了，关注业务逻辑优化或数据库优化的性能可以得到更多的性能回报

require 'benchmark'

array = (1..10_000_000).to_a

Benchmark.bmbm do |x|
  x.report("map") { array.map { |e| e } }
  x.report("map!")  { array.map! { |e| e }  }
end

Rehearsal ----------------------------------------
map   10.520000   0.500000  11.020000 ( 11.600892)
map!   9.500000   0.220000   9.720000 (  9.803323)
------------------------------ total: 20.740000sec

           user     system      total        real
map   10.260000   0.430000  10.690000 ( 10.838827)
map!   9.510000   0.090000   9.600000 (  9.727683)

呃，你关注过 each map collect 之间的性能差异么。。。

一般靠猜，根据处理形式来判断，比如会生成新对象的总会比不生成的慢。然后才是 Benchmark 对比

#1 楼 @jimrokliu map! 爆炸方法性能更优 不过真的在乎这点性能 真的要换语言了

#13 楼 @huacnlee 之前你教育另一小伙时是这样说的：

https://ruby-china.org/topics/28153 看 Rails Guides 不要猜

你到底猜不猜

跑 Benchmark 不需要先进行预热么

大多数不加！的函数相当于先 clone 一个原对象再直接对新对象调用加！的函数，但 map 例外。map 相当于建一个新的数组，再把待 map 的元素 push 进新数组，map! 相当于直接遍历并修改数组中的元素。 个人觉得应该几乎所有函数都是加！快一点吧。

#14 楼 @zhang_soledad 确实猜错了，有时候可能要仔细分析一下。例如有的算法可能爆炸方法就不占优。如：reverse!

#18 楼 @jimrokliu 爆炸方法更优 主要是因为 GC《ruby performance optimization》很详细的分析介绍了

#9 楼 @hi2016 我不觉得我不能做极客，我其实也很喜欢把一样技术背后的东西弄得清晰透彻，上次有这种感觉还是做c的时候。做 ruby 的接触得最多的是业务，还有很多时候在和同事扯淡。。。我确实有做个人项目的想法。。

#8 楼 @hooooopo 我必须说明我的言论很欠扁，我的意思是，既然 ror 已经走上低性能快速开发的道路，就没有必要再纠结这种性能上的小节，除非有巨量的数据要处理。ruby 的GIL作者自己已说明无法解决。

#11 楼 @azhao 你和我的态度一样，遇到具体问题具体需求的时候再深入：只要理论上可行加上别人有成功的案例，我就相信我能搞定。

#12 楼 @zhangjinzhu 没有，在没有需求的情况下都是些扯淡的问题。

#13 楼 @huacnlee 我拿到问题的时候也是这么猜的，后来被提问者鄙视了。让我关掉GC去测，当时我就蒙了。

#14 楼 @zhang_soledad 我是这么猜的，被提问者鄙视了。。

#19 楼 @zhang_soledad 看来要在刁钻的技术面试里撑得住场子，这书得列入书单啊。。。

#2 楼 @lgn21st 一直没回复你，我猜你的回答还有一个意思：你不想知道为什么吗？我的回答是：是的，我不想知道，如果我想知道的话，我相信我还是有那个能力搞清楚的。

map! 要快一点，benchmark 有人贴了，我们可以看看二者的实现部分

差别就在这儿

#28 楼 @izuo 从新分配了一块内存，读和写的不是同一块内存。数据小的话没什么差别，如果数据量大的话，cpu 的缓存命中率会下降吧