如果页面太长，会卡顿，时间挺长的 #280
Comments
|
是指录制还是回放的时候呢？ |
|
是录制的时候 |
|
能加您微信么，大佬 |
|
可以发邮件给我。 |
Yuyz0112
added a commit
that referenced
this issue
Aug 16, 2020
This issue was originally reported in #280 but may also relate to #167 and other potential performance issues in the recording. In #206 I implemented the new mutation observer which will defer the serialization of DOM, which helps us to have a consistent DOM order for the replay. In this implementation, we use an array to represent the `addQueue`. Whenever we need to consume the queue, we will iterate it to make sure there is no dead loop, and then shift the first item to see whether it can be serialized at the new timing. But this implementation may be very slow when there are a lot of newly added DOM since it will do an O(n^2) iteration. For example, if we have three newly added DOM `n1`, `n2`, `n3`, the iteration looks like this: ``` [n1, n2, n3] n1 -> n2 -> n3, consume n3 [n1, n2] n1 -> n2, consume n2 [n1] n1, consume n1 ``` We should have a better performance if te iteration looks like this: ``` [n1, n2, n3] n3, consume n3 [n1, n2] n2, consume n2 [n1] n1, consume n1 ``` Simply reverse the mutation payload does not work, because it does not always as same as the DOM order. So in this patch, we replace the `addQueue` with a double linked list, which can: 1. represent the DOM order in its data structure 2. has an O(1) time complexity when looking up the sibling of a list item 3. has an O(1) time complexity when removing a list item
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
请问这样的我应该怎么处理呢？
The text was updated successfully, but these errors were encountered: