Question

为什么React在处理大型列表（比如说100,000个）虚拟节点（例如渲染空的组件）时没那么慢，而且没有DOM更新？是否有任何技巧可以缩短这些瓶颈？

以下是两个不同的演示，允许在屏幕上添加许多项目，并在每个刻度上进行非常简单的更新（基于PIXI bunnymark）。要明确的是，虽然提示很受欢迎，但这不是关于React使用的问题（这会使我的代码解密很重要），这是关于React能够协调100,000个虚拟节点的问题：

纯

反应

现在 - 我知道React版本会变慢。但是什么导致差异如此激烈？换句话说 - 当没有DOM更新时，为什么React这么慢？（在平原上需要大约100,000个兔子才能达到React版本的8,000个，而普通版本仍然响应更快）

以下是关于反应实施的一些相关要点：

它使用PIXI的事实可能无关紧要，我猜测 - 因为在两个演示中都使用了它。直接WebGL或Canvas更新可能也会出现相同的问题，即使最终结果更快（双方都有）。
这个版本的架构可能有点难以阅读 - 所以用英语说它可能会有所帮助。从根本上说，所有路径都呈现null，更新只是传递给componentWillReceiveProps()中的PIXI。当然，拥有子节点的节点会渲染（）子节点，但这不会向DOM添加任何内容。
有人建议完全使用自定义渲染器 - 但我不确定为什么考虑到上述因素会产生影响。换句话说 - 如果元素都是虚拟的，那么渲染器真的会有所作为吗？更重要的是 - 是否有硬数据来支持这一说法，即瓶颈是可交换的渲染器？
考虑到PIXI有自己的场景图和差异算法，人们可能想知道为什么在这个世界中将React添加到混合中是值得的。这是一个有效的问题，但不在此范围内。
另一方面，有人可能想知道为什么PIXI而不是WebGL / Canvas。简短的回答是PIXI使许多事情变得简单，就像传播变换的嵌套层次结构一样。

总体而言 - 我的目标是拥有一个React树（或其他一些声明框架），允许编写类似的内容：

<Container position={pos}>
  <Container rotation={rot}>
    <Sprite texture={tex}/>
  </Container>
</Container>

将该地图直接映射到PIXI。

如果它具有高效性，那将是非常棒的。