Tcl eval 命令是否阻止字节编码? [英] Does Tcl eval command prevent byte coding?

问题描述

我知道在一些动态的解释性语言中，使用 eval 会减慢速度，因为它会停止字节编码.
在 Tcl 8.5 中是这样吗?
谢谢

I know that in some dynamic, interpreted languages, using eval can slow things down, as it stops byte-coding.
Is it so in Tcl 8.5?
Thanks

推荐答案

它不会阻止字节码编译，但无论如何它都会减慢速度.关键问题是它可以防止字节码编译器在编译期间访问局部变量表 (LVT)，强制通过哈希查找来访问变量.Tcl 有一个超快的哈希算法(我们已经对它进行了很多基准测试并尝试了很多替代方法；它是非常 热门代码)但是 LVT 有它的优势，因为这只是一个简单的 C 数组查找字节上路了.LVT 仅在编译整个过程(或其他类似过程的东西，例如 lambda 项或 TclOO 方法)时才正确知道.

It doesn't prevent bytecode compilation, but it can slow things down anyway. The key issue is that it can prevent the bytecode compiler from having access to the local variable table (LVT) during compilation, forcing variable accesses to go via a hash lookup. Tcl's got an ultra-fast hash algorithm (we've benchmarked it a lot and tried a lot of alternatives; it's very hot code) but the LVT has it beat as that's just a simple C array lookup when the bytes hit the road. The LVT is only known properly when compiling a whole procedure (or other procedure-like thing, such as a lambda term or TclOO method).

现在，我尝试制作这个特定案例:

Now, I have tried making this specific case:

eval {
    # Do stuff in here...
}

完全是字节码编译的，它大部分都可以工作(除了一些目前可以观察到但可能不应该观察到的奇怪的东西)，但对于我们使用的数量来说，这显然不值得.在任何其他情况下，无法在编译器运行时太精确地知道脚本这一事实会强制采用 LVT-less 操作模式.

be fully bytecode-compiled and it mostly works (apart from a few weird things that are currently observable but perhaps shouldn't be) yet for the amount that we use that, it's just plain not worth it. In any other case, the fact that the script can't be known too precisely at the point where the compiler is running forces the LVT-less operation mode.

另一方面，也不全是厄运和悲观.假设在 eval 中运行的 actual 脚本不会改变(包括不通过内部 concat 重新生成——多参数 >eval 永远不会得到这个好处)Tcl 可以在脚本值的内部表示中缓存代码的编译，尽管它是无 LVT 的，因此仍然有相当多的性能提升.这意味着这还不错，性能方面:

On the other hand, it's not all doom and gloom. Provided the actual script being run inside the eval doesn't change (and that includes not being regenerated through internal concat — multi-argument eval never gets this benefit) Tcl can cache the compilation of the code in the internal representation of the script value, LVT-less though it is, and so there's still quite a bit of performance gain there. This means that this isn't too bad, performance wise:

set script {
    foo bar $boo
}
for {set i 0} {$i < 10} {incr i} {
    eval $script
}

如果您有真正对性能敏感的代码，请在不使用 eval 的情况下编写它.扩展语法 — {*} — 在这里可以提供帮助，帮助程序也可以.或者用 C 或 C++ 或 Fortran 或...编写关键位(有关执行此操作的酷方法的详细信息，请参阅 critcl 和 fidl 扩展包，或者如果 DLL 有合适的load，则只需根据需要loadcode>*_Init 函数).

If you have real performance-sensitive code, write it without eval. Expansion syntax — {*} — can help here, as can helper procedures. Or write the critical bits in C or C++ or Fortran or … (see the critcl and ffidl extension packages for details of cool ways to do this, or just load the DLL as needed if it has a suitable *_Init function).

这篇关于Tcl eval 命令是否阻止字节编码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！