Office.js 性能:我应该在一个 Excel.run 函数中投入多少?

Office.js Performance: How much should I put into one Excel.run function?

我正在处理一些大型电子表格(约 30,000 行)和 运行 一些性能问题,并且有以下一些与性能相关的问题:

在一个 Excel.run 函数中,我可以或更好地填充多少?我需要考虑哪些事项来确定何时将事情分解为多个 Excel.run 调用?

一般来说,我应该在一次调用中创建多少个范围?

在我可能需要将一个大范围分成多个较小范围之前,我应该使用多大的范围?

打电话给 await ctx.sync() 或多或少会对此有所帮助吗?


编辑: 这个问题的动机是:

很抱歉没有尽快回到这个话题。

几点观察:

  1. 如果你正在操纵大量的范围(范围是特殊的),你肯定希望在尽可能大的块中进行操作(例如,将值设置为单个范围上的一个巨型数组,而不是逐个单元格地设置值并创建一堆 Range 对象)。创建 any new API 对象并不便宜,但是 Excel 范围 特别是 并不便宜。团队目前正在调查一些性能问题,一旦我们完成调查,我应该可以分享更多。

  2. 在内部实现方面,你可以把Excel.run当成任务容器(可能像C#中的"using"语句)?特别是对于 Ranges,如果你超过几千(你可以通过实验尝试),事情就会开始显着放缓。所以从这个角度来看,你确实希望尽快发布你的 Excel.run(不要暂停 10 分钟等待用户输入),并且 - 直到我们根据调查找到解决方法 I上面提到过——你可能确实想让你的 Excel.run-s 保持合理的小,让内存占用减少。

  3. 也就是说,除非您在 API 对象的 1000 个上创建 1000 个,否则在正常情况下每个 "context.sync" 或 "Excel.run" 都是进程边界或网络往返。因此,从这个角度来看,将上下文传递给辅助函数比拥有多个不同的独立等待 Excel.run-s.

  4. 更可取

如需更多信息,我鼓励您阅读 Yours Truly 所著的一本书 Building Office Add-ins using Office.js(但所有利润都用于慈善事业,这样当我向人们推荐它时就不必感到内疚了: -)).如果您好奇,内部实现有一个很长的部分(11 页),特别是对于范围,您可能会发现阅读“一种特殊(但常见)的情况:没有 ID 的对象”。您可能还会发现有关“更复杂的 context.sync 示例”的部分很有用,尤其是围绕我为“跨多个子例程拆分工作[=40] 规定的模式=]"

希望对您有所帮助!