Question

这发生在Ruby on Rails的View中，其中有另一个部分的哈希值。此哈希有大约20个键/值对。

有（在HAML中）

- if (some_conditon)
  = render :partial => 'some_name', :locals => a_hash.merge({ :extra => true })
- else
  -# a lot more processing, including concatenating the partials and return as json
  - some_var.each do |item| 
    - result_html << (render :partial => 'some_name', :locals => a_hash )
    -# etc
  - response.content_type = "application/json"
  = result_html.to_json

所以问题是，merge应该写成merge!吗？因为以后不再需要它，如果创建了新的哈希，将花费大量时间来创建这个新哈希（哈希中的20个项目）。如果进行了就地修改，它可以使用现有的哈希结构并向其中添加一个项目，这会快得多吗？

Answer 1

这是微观优化。正如所有这些问题一样，“我应该......？”的问题通过剖析并查看A）所讨论的代码是否占用了大量的时间来进行回答，以及B）这种变化导致了大部分的加速。如果A不是这种情况，请不要进入B.如果不是B，则更改不值得使代码不那么干净。

至于安全考虑因素，您不仅要考虑以后是否要在方法中使用该哈希值，还要考虑是否有任何其他对象可能引用了哈希值。如果从另一个对象获得此哈希并且该对象将其存储在实例变量中，则向哈希添加键将导致另一个对象看到变异版本。

Answer 2

此时此功能可能不需要，但如果您需要在六个月内扩展视图，我不会感到惊讶。在六个月的时间内，您可能会非常惊讶地发现在:extra => true阻止之后将if/else/end填入您的哈希值。

所以问问自己，在六个月的时间里你会更加惊讶：在你的哈希中找到:extra => true，或者在你的哈希中不找到:extra => true。没有完整的细节，很难说我更喜欢哪一个，我可以想象两条路径都有意义。

除非你的分析证明创建一个新的哈希表示可测量的处理量，否则我不会担心速度。

Answer 3

如果你担心速度，你可以很容易地测试它，否则使用merge（）

Answer 4

如果您确定修改现有哈希不是问题，那么您当然可以使用merge！。但是，我不确定它是否会比简单地使用merge更“快”。复制20个左右的对象的散列可能不是一个非常耗时的操作。但是，如果这是一个问题，你可以对不同的实现进行基准测试，看看你通过做另一个实现多少收益。

在Ruby中，如果以后不再需要哈希，那么使用hash.merge！（{...}）而不是hash.merge（{...}）会更好吗？

4 个答案: