spreadjs 16.2.6和17.1.4性能问题

调研编号：SJS-26406


上述两个表格针对没有树形的做了一下分析，内存没有太大变化，demo做了个console.time分析数据，初始化加载17.1.4版本用时：计算逻辑_Test: 101359.81005859375 ms  ;16.2.6版本用时：计算逻辑_Test: 48934.906982421875 ms 新版本加载慢了大约5秒左右；然后点击刷新按钮发现17版本比16版本大约慢了2秒左右，每次刷新获取加载时间不一致。内存之间没什么差距，感觉性能变慢了。


自己的项目用的16.0.7版本和17.1.4版本计算逻辑相差10几秒智20秒左右。性能分析也是慢了20秒左右。不知道我这样分析spreadjs从加载到显示是否有问题？有树形新版本会快很多，没有树形慢个几秒，十几秒左右。

您好，您的代码中使用了大量的findIndex来实现您自己的业务逻辑，其中涉及大数据量的循环操作，我们这边也没有特别好的方案能够优化。

Joestar.Xu 发表于 2024-9-19 13:40
您好，如果无法调整autoMerge的区域的话，目前除了之前的方案，没有其他更好的方案了。

好的，那findIndex不是性能占用80%，请问这个有啥好的方案解决吗

您好，如果无法调整autoMerge的区域的话，目前除了之前的方案，没有其他更好的方案了。

Joestar.Xu 发表于 2024-9-18 12:28
根据您目前的用例的情况来看，不建议您针对整个表设置autoMerge，而是针对部分需要autoMerge的列设置auto ...

您好，我们这边的列是动态生成的，所以并不知道哪些列需要设置autoMerge，所以我们是针对整个表设置autoMerge

wutao@digiwin 发表于 2024-9-18 10:36
您好，是的，我们这边有很多功能需要用到autoMerge，请问还有其他优化方法吗

根据您目前的用例的情况来看，不建议您针对整个表设置autoMerge，而是针对部分需要autoMerge的列设置autoMerge。

Joestar.Xu 发表于 2024-9-18 10:06
您好，就目前的情况来看，性能的差异是合理的，SpreadJS在加入新功能的时候需要注入一些插槽，从理论上来说 ...

您好，是的，我们这边有很多功能需要用到autoMerge，请问还有其他优化方法吗

您好，就目前的情况来看，性能的差异是合理的，SpreadJS在加入新功能的时候需要注入一些插槽，从理论上来说这些插槽不会生效，仅仅是执行一下就返回了。

但是在您目前的用例中存在2W*38的autoMerge区域，这个autoMerge区域会导致整个Sheet在运算时判断是否需要merge，也就需要依次执行getText->getFormatter->getActualStyle。

这样一来就会额外执行很多次插槽方法，即使插槽为空方法，但仍然会额外花费时间，在性能较差的机器上时间会更长。

Joestar.Xu 发表于 2024-9-14 14:40

您好，我刚刚测试了一下，把您那demo代码拷贝到两个版本中发现16版本性能还是比17版本性能快啊，快个7秒左右

Joestar.Xu 发表于 2024-9-13 11:16
您好，可以先设置：

sheet.options.allowCellOverflow = false;

好的，我这边调研看看，谢谢您了，麻烦您那边再看看哈，我个人觉得计算逻辑这一块可能还需要在进行优化