大文本计算性能优化

[Yeessang]

What problem does this feature solve?

首先感谢这个库
目前基于这个库在做业务，已实现文档锁定、批注polyline划线等
目前遇到的问题是，大数据量的文本或者表格在render的时候会出现卡顿
看performance监测，是render函数computeRowList，计算每行的信息时占用了太长时间
我想自己优化这点，但是这涉及到的代码或者设计有点多，请问作者有什么思路给到我能完成这个优化吗，或者我看官方文档中未来的feature也会有计算优化，这个部分什么时候能发布呢

What does the proposed API look like?

希望能回复，谢谢了

[claviering]

万字纯文本也正常。223 ms Scripting

[Hufe921]

编辑器存在性能问题的点：

1. 元素信息、行信息、页面信息等的数据计算
2. 页面渲染

现状：
页面渲染已经实现按需渲染不存在性能问题，目前性能问题主要集中在元素相关信息的计算上。

可行方案：

1. 减少元素信息计算的次数（尽可能使render函数下isCompute=false）
   目前已经把能想到不计算的场景都做了标注，所以这方面努力效果欠佳

2. 缩小需要计算元素的数量。准确判断信息更改影响的元素范围，而不是从头计算所有信息（优化方向）

目前准确判断影响范围难度较大，可以渐进优化
如：1. 超出1万字符时，在输入内容时，计算输入的内容是否会影响页面数量、行数量，如果不影响，仅追加计算的元素即可，避免全局计算
2. 在最后一页输入内容时，仅需计算最后一页的元素，避免全局计算

[Yeessang]

忽略了有很多表格的情况，即便只有万字，但是有很多表格存在的话，计算所占用的主线程时间还是过长，看了源码我大概明白可行方案的第二个方案的意思，因为我们这个业务比较急，我也会尝试着去改下。
还有最后一个问题，作者有关于这块优化的时间点吗？会有个大概的时间发布这块的优化吗，毕竟作者才是最了解整个架构的。
感谢了！

[ThunderYu]

用Rust或者C重写核心排版逻辑后编译成wasm调用应该对性能也有所提升，不过这个是更后面阶段才该考虑的事情了