异步友好的性能计数器

背景
互联网计算机可以托管完整的 dapp - 前端、后端和数据，用户可以将他们的 dapp 作为容器（智能合约）部署在互联网计算机上，每个容器最多可存储 96 GB 的数据，并在每个事务中执行最多 200 亿条 WebAssembly 指令。
与其他区块链不同，互联网计算机为开发者提供了大量资源，这给容器开发人员带来了真正的挑战：编写高效的容器代码，容器的效率越高，其所花费的 Cycles 就越少。
性能计数器是容器（智能合约）跟踪已完成工作量的方式，该信息可以用作优化代码的主要指标。
互联网计算机提供此系统 API 调用：

类型参数指定要返回哪个性能计数器，长期以来，互联网计算机仅支持 type 0 计数器 - 自当前消息执行开始以来容器已执行的 WebAssembly 指令数。
这个 type 0 计数器运行良好，许多开发人员每天都在使用它，但计数器仅对当前消息有效，并且在每个等待点后重置。
如何改进？
我们引入了一个新的调用上下文性能计数器（type 1）来跟踪跨等待点执行的 WebAssembly 指令。
比较性能计数器
考虑这个示例函数：

函数 ❶ 进行两次嵌套调用，❷ 等待它们，最后 ❸ 回复原始调用。
从开发者的角度来看，这只是一个功能，从用户的角度来看，这只是一次调用，但实际上，在幕后，存在三种消息执行：

• 原始调用将一直执行到第一个等待点；
• 然后对该调用的回复会触发第二次执行；
• 最后，另一个回复会触发最后一部分，该部分使用两个性能计数器回复原始调用。

有一个调用上下文来跟踪原始调用，互联网计算机为每个呼叫创建它并保留它，直到呼叫被应答或拒绝。
性能计数器 type 0 仅跟踪这三个消息的执行，它从 0 开始并上升到某个值 i，第一次等待后，它会重置并上升到 j，然后上升到 k。
另一方面，新 type 1 计数器存在于调用上下文中，因此它单调增加，直到原始调用得到答复，在此示例中，它从 0 开始，到达 i，i+j 然后到达 i+j+k。
结果是相似的，仅旧 type 0 计数器可以完成这项工作吗？
为了用计数器 type 0 获得与 i+j+k 相同的结果，应该在每次重置之前保存计数器：

即使这个简单的例子也变得像意大利面条一样，因为每个等待点都必须改变，想象一下更复杂的代码，带有许多嵌套函数和库调用……正确检测生产异步代码是一个挑战！
另一方面，新的调用上下文计数器仍然必须在函数末尾显式收集：

但在这种情况下，无需检测嵌套函数或库中的每个等待点，只有一个地方，就在计数器返回之前，这是未来代码检测和分析完全自动化的一大进步。
使用性能计数器
快速运行性能计数器示例（假设已安装 Internet Computer SDK）：

该示例函数返回两个值：旧计数器（type 0）和新计数器（type 1），由于新的调用上下文计数器包括所有三个消息执行，因此它报告的 WebAssembly 指令数量是原来的三倍：2100 万条，对比仅 700 万条。
请查看 GitHub 上的性能计数器示例以获取详细说明：

• github.com/dfinity/examples/tree/master/rust/performance_counters

新的异步友好性能计数器随处可用：

参考
后端开发人员指南 - 优化 Rust 容器：

• internetcomputer.org/docs/current/developer-docs/backend/rust/optimizing

Motoko 开发人员指南 - 优化容器：

• internetcomputer.org/docs/current/developer-docs/backend/motoko/optimizing

如果您有疑问或建议或只是想与互联网计算机开发人员和 DFINITY 工程师见面，请加入 forum.dfinity.org。

作者：Andriy Berestovskyy翻译：Catherine

-    往  期  推  荐    -

你关心的 IC 内容

技术进展 | 项目信息 | 全球活动

长按关注 IC 微信公众号

掌握最新资讯

＊添加小助手微信 comiocn 进交流社群