0

我正在定义一个新的 TCL 命令，它的实现是 C++。该命令是查询一个数据流，语法是这样的：

mycmd  <arg1>  <arg2> ...

这个想法是这个命令接受一个参数列表并返回一个列表，其中包含每个参数的相应数据。

我的同事评论说，最好只使用一个参数，当需要多个值时，只需多次调用该命令。

还有一些其他的讨论，但我们不能达成一致的一件事是性能。

我认为我的版本，参数列表应该更快，因为当我们想要多个参数时，通过 TCL 解释器是一次成本。

他的评论对我来说是新的-

  1. 函数实现被缓存
  2. 访问 TCL 函数比访问 TCL 数据更快

这个推理合理吗？

4

1 回答 1

0

如果您使用Tcl_EvalObjv调用命令，您将不会通过 Tcl 解释器。成本将是一个哈希表查找（或者更少，如果您重用Tcl_Obj*包含命令名称），然后您将执行该命令。否则，构造一个列表Tcl_Obj*（例如，用Tcl_NewListObj）然后调用Tcl_EvalObj几乎一样便宜，因为这是一种特殊情况，因为列表构造代码保证生成也是无替换命令的列表。构建一个普通字符串并通过Tcl_Eval(or Tcl_EvalObj) 的速度要慢得多，因为它必须被解析。（OTOH，连续多次传递相同 Tcl_Obj*的Tcl_EvalObj内容会更快，因为它将在内部编译为字节码。）

访问值（即Tcl_Obj*引用）非常快，只要这些值的内部表示与访问函数所需的类型相匹配。如果不匹配，可能会调用内部类型转换函数，而且它们通常相对昂贵。要了解内部表示，您可以考虑以下几点：

  • string— Unicode 字符数组
  • integer- 一个 C long（除非你溢出到任意精度的工作中）
  • list—Tcl_Obj*引用数组
  • dictTcl_Obj*— 映射到的哈希表Tcl_Obj*
  • script— 字节码版本
  • command— 指向实现函数的指针

好的，这些不是确切的类型（通常还有其他簿记数据），但它们是您应该认为的模型。

至于“哪个最快”，回答这个问题的唯一明智的方法是尝试一下，看看哪个是真正最快的：对于没有实际代码来预测它的任何人来说，答案将取决于太多因素。如果您从 Tcl 调用，则该time命令非常适合这种性能分析工作（这是它的设计目的）。如果您从 C 或 C++ 调用，请使用该语言的性能测量习语（我不知道，但会在 Stack Overflow 上搜索）。

我？我建议编写 API 尽可能清晰和干净。描述实际操作，不要扭曲一切以试图挤出额外的 0.01% 的性能。

于 2013-03-21T07:23:18.397 回答