问题描述
我正在调查virtual-dom，我想知道virtual-dom是否比手动操作更快。现在我明白，virtual-dom和diff算法可以防止不必要的重新流动，例如当我们想要改变这一点时： < DIV>
< div> a< / div>
< div> b< / div>
< / div>
对于这一个：
< DIV>
< div> c< / div>
< div> d< / div>
< / div>
所以当我们使用直接操作时，我们可能有4个重新流动：2去除每个div创造新的。因为我们应该创建新的元素（也许可以从dom创建新的dom - >设置属性 - >安装到文档，然后直接编辑dom属性）。从另一方面来说，我们有快速的差异算法，它可以生成2个补丁，只是为了替换我们的div的内容，我们可能会有1次重新流动。 （如果我在编写重新流动时出错，请告诉我）
在这种情况下，virtual-dom可能是规则，但是当我们有2个真正不同的树我们不会从diff获得很多好处，所以我们将防止一些重新流动，也许，但是生成新树并运行diff和patch的时间要长得多。这是我的第二个问题。例如，在库，他们说：所以，而不是在应用程序状态更改时更新DOM，您只需创建一个虚拟树或VTree。每次当我需要改变我的观点时，建立一个新的虚拟树是真的很好吗？
当然，我会尝试进行一些测试来评估性能，但是我想知道一些更多的技术方面和原因，为什么virtual-dom真的更好，或者也许不是吗？
如果您批量DOM操作操作和，请勿将它们与需要读取布局的操作交错状态（例如读取计算的样式，计算偏移量），那么所有这些操作只会导致一次回流。
浏览器的回流和重绘算法也相当先进天，仅调整文档的部分，只需重新合并移动的图层，而不改变它们的尺寸。
如果您关心性能，应该使用浏览器的性能分析工具，看看实际上减缓了什么，以及是否可以在进行过早优化之前优化本机实用程序。
我认为虚拟dom更适用于某些（例如服务器）发出全页DOM树但您只想应用差异的情况。
I'm investigating virtual-dom right now, and I'm wondering whether virtual-dom is really faster than manual manipulation with view. Now I understand that virtual-dom and diff algorithm can prevent unnecessary re-flows, for example when we want to change this:
<div>
<div>a</div>
<div>b</div>
</div>
To this one:
<div>
<div>c</div>
<div>d</div>
</div>
So when we use direct manipulation we will have probably 4 re-flows: 2 for removing each div and for creating new one. We will also have more manipulation with dom, because we should create new elements (Maybe removing from dom -> creating new dom -> setting properties -> mounting to document is faster then just direct editing dom properties?). From the other side we have fast pretty diff algorithm that generate 2 patches just to replace content of our divs, probably we will have 1 re-flow. (if I made a mistake while writing number of re-flows, please tell me)
In this case virtual-dom probably rules, but when we have 2 really different trees, we will not have a lot of benefits from diff, so we will prevent some re-flows, maybe, but time for generating new tree and running diff and patch is much longer. And here is my second question. For example, in the motivation to https://github.com/Matt-Esch/virtual-dom library, they say: "So instead of updating the DOM when your application state changes, you simply create a virtual tree or VTree". Is it really nice to build a new virtual tree every time when I need to change something on my view?
Of course, I will try to make some test to evaluate the performance, but I want to know some more technical aspects and reasons why virtual-dom is really better or, maybe, not?
If you batch your DOM manipulation operations and do not interleave them with operations that need to read the layout state (e.g. reading computed styles, calculating offsets) then all those manipulations taken together will only cause a single reflow.
The reflow and repaint algorithms of browsers are also fairly advanced these days, only adjusting parts of the document and simply re-compositing the moved layers without repainting them if they don't change their dimensions.
If you are concerned about performance you should use the performance profiling tools of your browser and see what is actually slowing you down and whether it can be optimized with native utilities before making premature optimizations.
I think virtual dom is more meant for situations where something (e.g. the server) emits a full page DOM tree but you only want to apply the differences.
这篇关于当虚拟主机比手动操作更快时？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！