Respo 的性能优化和难点

[tiye]

早期版本以 Deku 作为参考, 实现根据 ClojureScript 的不可变数据方式来做.
中间也经历过演化, 特别是事件处理逻辑比较绕. 算法部分 diff 算法研究不够深入.
global states 跟 effects 是后续加入的, 比较偏执.
相对于 React 来说, 局部状态. 组件内部的数据逻辑和生命周期, 实在太弱了.

Respo 和 Deku 的对比

• 没有实现各种生命周期和 Hooks API, 没有 Context.
• Global states tree 存储组件状态, 而不是像 React 存储在组件局部.
• 没有在一个流程内完成 diff 和 update, 而是先得到 changes 数组, 然后再开始 patch DOM.
• 基于不可变数据结构, 本身数据结构存在性能上的劣势.(不过优化方案倒是成熟点)

Diff 算法

向前查看 N 个节点(似乎是 16)判断 children 是否增删, 性能不够.

事件处理机制

全局的 component tree 上边有 coord 保存节点位置信息.
点击事件当中有 coord 的信息, 这时候需要反过来到 component tree 上查找事件.
这个地方特别的是, 组件当中描述的事件是通用的, 只是用来标记事件是否存在以及 coord 信息.
所以点击时候, 是需要在 component tree 当中去找到真实的事件再进行调用的.
这样对 diff 那边有一些好处, 因为 diff 的时候只管事件是否存在, listener 的闭包有改变, 是不产生 diff 的.

这样优化的时候缓存组件, 也就要根据这个事情进行考虑.
比较麻烦的是, coord 是需要比较晚才能确定的, 不能缓存,
或者说组件调用在不同位置代码是一样的, coord 是在渲染才能确定的, 无法缓存.

组件树渲染过程的复用

由于 React 中 state 改变, 组件计算是从局部的组件开始的, 能对应到上次渲染的结果,
这样是比较容易进行判断的, 就跟当前 class instance 直接判断就好了.
Respo 做了分离, 因而就需要手动控制, 跟旧的树进行对比.
当时做的方案是存一棵树, 新的树计算过程就以已有的树对应的分支作为参数进行计算,
这样的好处是, 如果发现参数一致, 就可以直接复用已有的这棵树了. 节省 diff 的时间.

注意, 虽然 React 当中用 shallow equal 的方式, 甚至引用相等的方式一致性,
实际在 cljs 当中, 数据要判断, 还是需要递归判断整个结构的.
引用一致只是特殊情况. 而且判断具体跟 persistent data 的实现有关系.
现在 calcit-js 版本的 Respo 用的是 ternary-tree, 那么这个性能的因素也发生改变了.

Memof 方案

前面说的计算过程当中使用上次计算得到的树的编码方式, 对实现逻辑来说侵入性比较大.
我后来考虑如果找更自然的方法, 就是直接用 memoization 做.
而真实场景, memoization 保存的信息是需要借鉴 GC 的方式进行清理的, 否则占用大量内存.
从 React 的角度来说, 只有上次计算存在而且这次继续计算依然存在, 才会保留对应信息.
目前 memof 的设计思路, 只是简单判断了一下, 循环多次, 数据没有被触碰到超过一定次数, 就丢弃.
这个策略还是比较粗略的, 以后还是想想什么办法可以监测定量一下.

之前版本 memof 使用的时候, 是用 macro 配合插入访问缓存的代码.
现在的版本 memof-call 通过高阶函数手动调用, 更加灵活.

[tiye]

前几天对事件处理部分用到的 coord 进行了重构, 性能提升明显 https://github.com/Respo/respo/pull/35/files .

事件处理的过程也算梳理了一下. 大致还是上边的叙述的,
但是重构之后, coord 是通过后续的逻辑手动计算得到的, 而不再在 render 计算的树当中保存.
达到的效果呢, 一个是去掉了之前的 render-markup 加 coord 的过程, 减少了明显内存开销,
另一个是这样优化后是一个统一的 tree 结构, 修复了之前的问题, 现在 memof 返回后, 通过引用判断一致成为了可能.

目前代码当中用到的两个 coord 变量,

• 一个变量名直接是 coord, 就是节点的位置信息, 准确说是渲染生成的树当中的位置信息,
  比如是在一个组件中, coord 也会带上组件的 :name 信息在里边,
  而子节点, 如果有 list 指定的 key, 也会用这个 key, 用于后面的事件位置查找.
• 另一个变量名 n-coord, 单纯对应的最终 DOM 上的纯数字标记的位置.

现在组件树展开的过程, coord 是不参与的, 还是那个例子, 同样一个组件可能用在多个位置, coord 会不同,
然后在生成 DOM 树或者更新 DOM 节点的过程中, 在函数递归调用当中维护 coord 和 n-coord.
这样, 前面部分的性能就优化掉不少了. 至于 diff patch 算法本身的优化, 目前没有改进.

就这个优化而言, 也就回到了函数式本身的性能开销上边来了,
比如数组, 先过滤掉 2 的倍数, 再过滤掉 3 的倍数, 思维上直观操作, 就是过滤两遍,
这个也是函数式编程抽象化的代码习惯性的写法, 这不仅是执行两次, 也产生了多一个数组, 占用对应的内存.
作为对比的过程式的编码, 就比较容易意识到其中的性能问题, 从而快速减少开销.
而函数式编程, 这一贯的编码方式, 很容易到处积累小的性能开销, 越来越多.

倒不是说函数式编程一定会慢. 应该说, 这就抽象和简洁所随之而来的代价.
函数式编程经常对一个新的状态就递归函数定义出新的局部变量, 状态的分离是挺清晰的, 比维护可变状态更精确.
然而, 函数式编程习惯上只是从数学角度考虑如何如何, 而数学本身没有"计算消耗时间"这个维度.
当时间这个维度被纳入程序当中需要进一步精确模拟时, 函数式的代码也会随之变得复杂.
而这当中比较可能就是我现在遇到这种, 多想办法复用已有的内存结构, 减少开销.

[tiye]

为什么要函数式编程, 而不是通用的 JavaScript 的写法?

我前几天本来想找找 preact 做一下组件状态对比的, 但是翻开代码, 发现内容好多.
preact 对于事件有做非常详细的处理, 而且精确到一些名称前缀, 此外类型方面当然还更多.
而反观 Respo, 事件系统极为粗略, 只是说能运行. 如果别人拿去一旦用到不一样的场景, 马上就会发现问题.

但是这样一比较下来, Respo 的代码真的算是很简单明了了, expand, diff, event resolve, patch DOM, 步骤分得很明确.
preact 当然因为代码当中做了大量的兼容, 组件渲染部分就显得逻辑耦合较重, 不那么明了.
这也算符合我初衷吧, 当时写 Respo 就为了试验 FP 的 MVC, 为了简洁清晰, 为了能自己进行迭代.
分开几个点说的话, 我对自己用的工具代码的期待

• 一方面有抽象强大的抽象能力, 高阶函数当然很强大了, macro 也算一种特殊的补全,
• 另一方面代码能遵循一些 law, 容易调试定位 bug, 而不是功能耦合了就复杂度爆炸.

对于 Vue 和 Svelte 的态度, 我从 React 这边能感受到只用函数的局限性,
某些功能就该从语法糖从代码生成的角度去实现, 从而整合掉更多的细节,
这方面 Lisp 也很难达成, 因为 Lisp 语法有着 S 表达式这个局限, 整合不极致, 更不用说配合 IDE.

不过 Vue Svelte 编译方案, 也会有编译器实现的难点,
要做深度整合, 就希望源码当中能提取出更多有用的信息, 用来优化或者验证,
然而用户来说, 却不可能真乐意写的非常非常细碎, 把所有东西标记给编译器去识别,
而这时定义的 template 和 component syntax, 也很有可能对使用造成局限,
抽象能力强了吧, 跟 React 这样编译器拿不到很多信息,
信息特化了吧, 就跟以前的 template engine 那样写逻辑受限招人烦.
而且我以前用这类方案还有报错因为 codegen 太复杂报错难定位的问题,
整个绕下来就很考验框架作者的编译器功力了... 这事情我这点精力可做不来.

另外一个方向是对于 PureScript Elm 方案的态度,
首先有一点, 这些语言语法真是烦呢, 我写惯了 cljs 可受不了天天写这玩意.
从类型的角度说, 我确实很希望从 FP 类型系统的层面强化 Respo.
Respo 每当重构就会发现一些小问题, 没有 Nim 或者 ts 代码被类型检查的那种可靠性.
而且跟 PureScript 那样的严格的类型约束做对照的话, Respo 极为舒散,
从代码的正确性来说, 没有强大的类型系统, 隐患是实实在在的.

只是说我碍于代码量的问题, 到目前为止还不情愿从 cljs 这个舒适区离开,
js UI 代码往往涉及到很多的属性样式等操作, cljs 就非常灵活,
等到 PureScript 去做, 可想而知对各种属性做类型化以后, 需要涉及到多少多工作,
即便我借助社区的东西能最后把框架拼出来, 使用时候代码太啰嗦可怎么办.
还有一个担心是 cljs 毕竟投入多年优化不可变数据性能, PureScript 现在做到什么程度呢?

最后还是绕回来说为什么不选 js 的事情,
抽象能力, 代码可靠性. 我对 cljs 在这方面都更有信心,

• 抽象能力来说, cljs 高阶函数, 一切皆是表达式, 一致性很强,
  macro 也是补助. 另外注意的是有不可变数据配合的高阶函数是更有可预测性的.
• 可靠性, 这个主要还是从不可变数据还有状态隔离带来的,
  在 js 当中由于多个位置维护某个可变数据导致错误难定位, 老问题了..

再往大了说, 我上面说想要抽象甚至 codegen 的能力, 基于 js 那还得再上 Babel 才能玩起来啊, 栈很长.
而代码正确性, js 不行了, 得上 ts, 但是 ts 类型系统相比 PureScript,
我完全有理由认为基于 Haskell 设计的 PureScript 比基于 js 搭建的 ts 更值得研究.
从探索方案和研究方案的角度来说是这样了. cljs 廉价, 同时善于抽象和可预测.

唉, 至于说真实项目的实用性和普适性, 想想 preact 源码当中那些细节, 真是太大的话题了.