用于填充 TCL 阵列的纯 TCL 与 TCL C API 的性能答案

【问题标题】：Performance of Pure TCL vs TCL C API's for populating a TCL array用于填充 TCL 阵列的纯 TCL 与 TCL C API 的性能
【发布时间】：2012-07-26 18:16:07
【问题描述】：

与使用 TCL C API 读取文件和填充 TCL 数组相比是否会快得多对标准 TCL 做同样的事情。我有一个大约 100+MB 的大文件，我需要读取并设置一些哈希条目。使用 TCL C API 似乎最多不能提供 2 到 4 倍的速度优势。这是平常还是我错过了什么？

【问题讨论】：

标签： tcl

【解决方案1】：

在这种情况下，您不太可能获得很大的性能提升，因为当您从 C API 设置数组条目时，如果您只是编写代码，您将承担大部分成本作为 Tcl 在一个过程中。特别是，通过使用低效的子 API，您可以很容易地获得更差的性能；一些 Tcl 的 API 函数不是很快（例如，Tcl_SetVar），但它们被保留是因为使用它们的大量现有代码（以及更快的函数需要使用更多 C 代码的事实）。请记住，设置一个数组元素需要强制哈希表查找，而且这些都是有实际成本的（尽管 Tcl 使用了一个非常快——如果相当愚蠢的话——哈希）。

更重要的是，您可以通过使用 Tcl 列表或字典（取决于您要存储的确切内容）获得更好的性能，并且这些的 C API 非常快（特别是对于列表，它们实际上是 @987654322 的 C 数组@ 参考）。我不知道这样做是否适合您的目的。

【讨论】：

Tcl 的散列函数实在是太牛了，我一直在努力研究它是否可以改进，但要真正改进它真的很难。在 Tcl 脚本中最常见的情况下，为更好地分配密钥所做的任何事情都会使函数变得相当慢（是的，我尝试了一大堆函数）。我认为这是一个相当令人失望的结果。（不过，它确实摆脱了一些邪恶的最终确定错误。）
谢谢多纳尔。我将尝试看看我们是否可以使用列表而不是使用数组来改进原始 TCL 代码。

【解决方案2】：

C API 主要是为了让您编写 Tcl 扩展，并且只公开编写“纯 Tcl”本身的例程。在您描述的情况下，我不希望看到太多的性能差异，请记住：

过早的优化是万恶之源（或至少大部分它）在编程中。

计算机编程作为一门艺术（1974 年），Donald Knuth

【讨论】：

【解决方案3】：

如果您确实需要加载大量数据，也许像 NAP (http://wiki.tcl.tk/4015) 或类似的扩展是合适的？

【讨论】：

schlenk，我正在使用 flex 和 bison 处理输入文件，然后将其转换为数组。不确定 NAP 是否对我有帮助。