我正在定义一个新的TCL命令，其实现是C ++。该命令用于查询数据流，语法如下：
mycmd <arg1> <arg2> ...
这个想法是这个命令获取一个参数列表并返回一个列表，其中包含每个参数的相应数据。
我的同事评论说，最好只使用一个参数，当需要多个值时，只需多次调用该命令。
还有其他一些讨论，但有一点我们不能互相认同，那就是表现。
我认为我的版本，参数列表应该更快，因为当我们需要多个参数时，通过TCL解释器需要一次性费用。
他的评论对我来说是新的 -
- 函数实现已缓存
- 访问TCL功能比访问TCL数据更快
这个推理听起来了吗？
答案 0 :(得分：0)
如果使用Tcl_EvalObjv来调用命令，则不会通过Tcl解释器。成本将是一个哈希表查找（或更少，如果您重用包含命令名称的Tcl_Obj*），然后您将执行该命令。否则，构建列表Tcl_Obj*（例如，使用Tcl_NewListObj）然后调用Tcl_EvalObj几乎同样便宜，因为这是一个特例，因为列表构造代码保证生成也是无替换命令的列表。
构建一个普通字符串并通过Tcl_Eval（或Tcl_EvalObj）传递该字符串要慢得多，因为必须对其进行解析。 （OTOH，连续多次将相同的 Tcl_Obj*传递给Tcl_EvalObj将更快，因为它将在内部编译为字节码。）
访问值（即进入Tcl_Obj*引用）非常快，提供这些值的内部表示与访问函数所需的类型相匹配。如果存在不匹配，则可以调用内部类型转换功能，并且它们通常相对昂贵。要了解内部表示，请参考以下几点：
string - unicode字符数组integer - 一个C long（除非你进行任意精确的工作）list - Tcl_Obj*引用数组dict - 将Tcl_Obj*映射到Tcl_Obj* script - 字节码版本command - 指向实现函数的指针好的，那些不是确切的类型（通常还有其他簿记数据），但它们是你应该想到的模型。
对于“哪个是最快的”，回答问题的唯一理智方法是尝试并查看哪个是真实的最快：答案将取决于没有实际代码预测它的任何人的太多因素。如果你从Tcl调用，time命令非常适合这种性能分析工作（它就是它的设计目的）。如果您使用C或C ++进行呼叫，请使用该语言的性能测量习惯用法（我不知道，但会搜索Stack Overflow）。
自己？我建议尽可能将API编写为清除。描述实际操作，不要扭曲所有内容，试图挤出额外0.01％的性能。