Tcl源vs Tcl包

Question

假设我不想给出每个源代码的完整路径，什么时候我会选择tcl包而不是tcl源代码？是否需要比源代码更快的包？

我知道哪些包可以保护我们避免两次源码，这有问题吗？我只采购函数，所以我不介意两次采购函数，但是这样会有性能问题吗？

Answer 1

当然，这也是一个性能问题。考虑一下当你运行一个源命令时会发生什么：

• 必须打开提供给源命令的路径。

操作系统检查该路径的权限，解析符号链接。对于您的特定情况，这是次要的。对于一些反复检查文件路径的应用程序(例如web服务器)来说，这可能是一个大问题。

• 该文件被读入。磁盘I/O总是很慢。

• 文件被解析和解释。解析总是很慢。

Tcl有一个简单的规则集，所以它的解析速度可能比其他的要快。

• 因为你的函数被替换了...这里的问题是，字节码编译器现在会忘记任何已经就位的优化，函数在第一次使用时会比平时运行得慢。

始终知道您的程序正在使用哪些资源(cpu、磁盘、内存、网络)，并尽量减少使用。

观点:你会发现人们只是说，“获得更好的硬件”。这些人都是傻子，这就是为什么大多数网络都很慢的原因。他们不必要地浪费资源。

Answer 2

看看你的核心问题：

是不是package require比source快？

它们不是直接可比的。

与脚本文件相比，包是一个更高级的概念，通常是通过对一个或几个文件执行source来实现的。还有一个缓存机制，所以当你第一次执行package require时，它肯定会比source慢得多(因为如果包管理子系统不能识别你所请求的包，它需要搜索你得到的包，这实际上涉及到在相当多的pkgIndex.tcl文件上使用source )，后续对package require的调用可能会更快，因为包不会加载两次。一旦建立了内部索引(通常是每个解释器一次的开销)，与直接source其实现文件相比，已知但未加载的包的package require速度并不会太慢。除了“更高级别”的事情正在发生:包可能根本不是由你可以source的东西实现的，而是可能使用动态链接库的load。或者它可以做一个混合。这就是包的事情:您通常需要知道的是功能有一个名称和版本。这与直接source不同，在直接file中，您需要知道代码的确切位置(如果代码位于已知的固定位置或相对于当前脚本的位置，则很容易)，并且该文件正是您所需要的。通常，最好将策略(例如package require foobar 1.2.3)从实现(例如source -encoding utf8 /usr/local/lib/tcl/packages/foobar_1.2.3/foobar.tcl)中分离出来。

包是一次性的，其后果是它们不打算创建对象的实例和类似对象的东西(除了那些在API中有效地记录了单例的东西)。您可以使用package require来获取构造命令(可能是类)，然后在需要时使用这些命令来创建所需的实例。