我正在处理一些大型电子表格(约 30,000 行)并遇到一些性能问题,并有以下一些与性能相关的问题:
我可以,或者更好的是,我应该塞进一个Excel.run
功能?我需要考虑哪些事情来确定何时将事情分解为多个Excel.run
call?
一般来说,我应该在一次调用中创建多少个范围?
在我需要将一个大范围分成多个较小范围之前,我应该使用多大的范围?
会打电话await ctx.sync()
或多或少经常做一些与此相关的事情来提供帮助?
EDIT:这个问题的动机是:https://stackoverflow.com/a/44424045/3806701 https://stackoverflow.com/a/44424045/3806701
很抱歉没有早点回到这个话题。
几点观察:
如果您正在操纵大量ranges(范围很特殊),您肯定希望在尽可能大的块中执行它们(例如,将值设置为单个范围上的一个巨型数组,而不是逐个单元格设置值并创建一堆 Range 对象)。的创建any新的 API 对象并不便宜,但 Excel Ranges 很便宜特别不便宜。团队目前正在调查一些性能问题,一旦我们完成调查,我应该能够分享更多信息。
从内部实现来看,你可以这样想Excel.run
作为任务容器(也许像"using"
C# 中的语句)?特别是对于范围,如果你超过几千(你可以尝试一下),事情确实会开始显着减慢。所以从这个角度来看,你确实想释放你的Excel.run
宜早不宜迟(不要暂停 10 分钟等待用户输入),并且 - 直到我们根据我上面提到的调查找到解决方法 - 您可能确实希望保留您的Excel.run
-s 相当小,以减少内存占用。
话虽这么说,除非您要创建数千个 API 对象,否则在正常情况下,每个“context.sync”或“Excel.run”都是一个进程边界或网络往返。因此从这个角度来看,将上下文传递给辅助函数比拥有多个不同的独立等待 Excel.run-s 更好。
欲了解更多信息,我鼓励您阅读使用 Office.js 构建 Office 加载项 https://leanpub.com/buildingofficeaddins/,你的真实的一本书(但所有利润都捐献给慈善机构,这样当我向人们推荐它时我就不必感到内疚:-))。如果您好奇的话,有一个很长(11 页)的关于内部实现的部分,特别是对于范围,您可能会发现阅读它很有趣“特殊(但常见)情况:没有 ID 的对象”。您还可以找到有关“的部分更复杂的 context.sync 示例“很有用,特别是围绕我规定的模式”将工作分配到多个子例程"
希望这可以帮助!
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)