1

这发生在 Ruby on Rails 的视图中，其中有另一个部分的哈希值。这个散列有大约 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!吗？因为以后不再需要它，如果创建一个新的hash，那么创建这个新的hash（hash中有20个项目）会花费大量的时间。如果进行就地修改，可以使用现有的哈希结构，并在其中添加一项，这样会快很多吗？

4

4 回答 4

2

这是一个微优化。与所有此类问题一样，“我应该……吗？”的问题。通过分析和查看是否 A) 有问题的代码开始占用大量时间，以及 B) 更改导致很大的加速来回答。如果 A 不是这种情况，请不要继续 B。如果 B 不是这种情况，那么更改就不值得让代码变得不那么干净。

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

于 2010-08-02T23:50:32.807 回答
1

目前该功能稍后可能不需要它，但如果您需要在六个月后扩展视图，我不会感到惊讶。在六个月的时间里，你可能会非常惊讶地发现在这个块:extra => true之后塞进了你的哈希。if/else/end

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

我不会担心速度，除非您的分析表明创建新哈希代表可衡量的处理量。

于 2010-08-02T23:49:13.603 回答
1

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

于 2010-08-02T23:51:59.687 回答
1

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

于 2010-08-02T23:53:35.140 回答