在Object.assign或spread运算符上使用immutable.js的优点

Question

到目前为止,大多数"起始锅炉板"和一些关于react/redux的帖子我都看到鼓励使用immutable.js来解决可变性问题.我个人依赖Object.assign或传播运算符来处理这个问题,因此在immutable.js中并没有真正看到优势,因为它增加了额外的学习,并且从用于可变性的vanilla js技术转移了一些.我试图找到切换的正当理由,但是因为我无法在这里询问为什么它如此受欢迎.

Answer 1

这完全取决于效率.

持久数据结构

持久数据结构通过始终产生新的数据结构来保持其自身的先前版本.为了避免昂贵的克隆,仅存储与先前数据结构的差异,而在它们之间共享交集.这种策略称为结构共享.因此,持久数据结构比使用Object.assign扩展运算符克隆要高效得多.

Javascript中持久性数据结构的缺点

不幸的是,Javascript本身不支持持久数据结构.这就是immutable.js存在的原因,它的对象与普通的旧Javascript有很大的不同Object.这导致更冗长的代码和持久数据结构到本机Javascript数据结构的大量转换.

关键问题

immutable.js的结构共享(效率)的好处何时超过其缺点(冗长,转换)？

我想,当整个数据结构的克隆和垃圾收集变得更加昂贵时,图书馆只会在拥有大量广泛对象和集合的大型项目中获得回报.

Answer 2

我已经为多个不可变库创建了性能基准,脚本和结果位于immutable-assign(GitHub项目)中,这表明immutable.js针对写操作进行了优化,比Object.assign()更快,但是,它读取操作较慢.以下是基准测试结果的摘要:

-- Mutable
Total elapsed = 50 ms (read) + 53 ms (write) = 103 ms.

-- Immutable (Object.assign)
Total elapsed = 50 ms (read) + 2149 ms (write) = 2199 ms.

-- Immutable (immutable.js)
Total elapsed = 638 ms (read) + 1052 ms (write) = 1690 ms.

-- Immutable (seamless-immutable)
Total elapsed = 31 ms (read) + 91302 ms (write) = 91333 ms.

-- Immutable (immutable-assign (created by me))
Total elapsed = 50 ms (read) + 2173 ms (write) = 2223 ms.

因此,是否使用immutable.js将取决于应用程序的类型及其读写比率.如果你有很多写操作,那么immutable.js将是一个不错的选择.

过早优化是万恶之源

理想情况下,您应该在引入任何性能优化之前对应用程序进行概要分析,但是,不变性是必须尽早决定的设计决策之一.当您开始使用immutable.js时,您需要在整个应用程序中使用它来获得性能优势,因为使用fromJS()和toJS()与普通JS对象互操作是非常昂贵的.