与两个元素的关联和update / assoc之间的差异(Differences between assoc

与两个元素的关联和update / assoc之间的差异(Differences between assoc-in with two elements and update / assoc)

我已经做了一段时间的事情(assoc-in my-hash [:data :id] 1) ，它看起来很好。

最近，由于我很少有两个以上的级别，我注意到我可以做到(update my-hash :data assoc :id 1) ，这听起来完全不同，但返回相同。

所以，我想知道，在性能上有什么不同吗？ 你认为这种方式比其他方式更具可读性吗？ 更惯用吗？

update / assoc觉得它对我来说更加昂贵，但我真的比联想更喜欢它，这使我每次看到它时都会停下来思考。

I've been doing for a while things like (assoc-in my-hash [:data :id] 1), and it looks fine.

Recently, since I rarely have more than two levels, I noticed I can do (update my-hash :data assoc :id 1), which sounds totally different, but returns the same.

So, I wonder, is there any difference in performance? Do you think it's more readable in one way than the other? More idiomatic?

update / assoc feels like it's more expensive to me, but I really like it better than assoc-in, which makes me stop to think each time I see it.

最满意答案

当谈到表现时，衡量总是很好的。 理想情况下，你会组装一张逼真的地图（无论你的地图是大还是小，都会对各种操作的相对成本产生一些影响），并用Criterium两种方式尝试：

(require '[criterium.core :as c]) (let [m (construct-your-map)] (c/bench (assoc-in m [:data :id] 1)) (c/bench (update m :data assoc :id 1)))

在这里， update + assoc是assoc-in的展开版本，它不需要辅助向量来保存键，所以我期望它比assoc-in更快。 但是（1）通常我不会担心在这样的事情上存在微小的表现差异，（2）当我在意的时候，再次测量比猜测更好。

（在我的盒子里，使用Clojure 1.9.0-alpha14，由于我的小测试图(assoc (into {} (map #(vector % %)) (range 20)) :data {:id 0}) ％％））， update + assoc确实在〜282 ns更快， (assoc (into {} (map #(vector % %)) (range 20)) :data {:id 0}) 。）

最终，大部分时间的可读性将是更重要的因素，但我认为一般来说，一种方法比另一种方法更可读。 如果你有一个→链已经多次使用assoc-in或update ，为了保持一致（为了避免让读者想知道“这个东西真的不同”），重复相同的函数可能会更好。 如果你有一个你控制的代码库，你可以采用一种“房子风格”，这种风格有利于一种方法。 等等

我可能会assoc-in大多数时候看到assoc-in更具可读性 - 它使用单个“动词”，并一目了然地清楚更新的（单一确切）路径 - 但如果您更喜欢update + assoc并期望在您的代码库中保持其使用一致性，这当然也很好。

When it comes to performance, it's always good to measure. Ideally you'd assemble a realistic map (whether your maps are big or small will have some impact on the relative cost of various operations) and try it both ways with Criterium:

(require '[criterium.core :as c]) (let [m (construct-your-map)] (c/bench (assoc-in m [:data :id] 1)) (c/bench (update m :data assoc :id 1)))

Under the hood, update + assoc is sort of the unrolled version of assoc-in here that doesn't need the auxiliary vector to hold the keys, so I would expect it to be faster than assoc-in. But (1) ordinarily I wouldn't worry about minor performance differences when it comes to things like this, (2) when I do care, again, it's better to measure than to guess.

(On my box, with Clojure 1.9.0-alpha14, update + assoc is indeed faster at ~282 ns vs ~353 ns for assoc-in given my small test map of (assoc (into {} (map #(vector % %)) (range 20)) :data {:id 0}).)

Ultimately most of the time readability will be the more important factor, but I don't think you can say in general than one approach is more readable than the other. If you have a → chain that already uses assoc-in or update multiple times, it may be preferable to repeat the same function for the sake of consistency (just to avoid making the reader wonder "is this thing really different"). If you have a codebase that you control, you can adopt a "house style" that favours one approach over the other. Etc., etc.

I might see assoc-in as a little more readable most of the time – it uses a single "verb" and makes it clear at a glance what the (single, exact) path to the update is – but if you prefer update + assoc and expect to keep their use consistent in your codebase, that's certainly fine as well.