我正在处理一些大型电子表格（约 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(使用前将#替换为@)
