【发布时间】：2020-05-08 00:59:47
【问题描述】：
假设我不想在每个源中给出完整路径，我什么时候会选择 tcl 包而不是 tcl 源？包需要比源更快吗？
我知道哪些软件包可以保护我们免于重复获取代码，这是一个问题吗？我只是采购功能，所以我不介意要采购两次的功能，但这有性能问题吗？
【问题讨论】：
标签： performance tcl
【发布时间】：2020-05-08 00:59:47
【问题描述】：
当然存在性能问题。 想想当你运行一个源命令时会发生什么：
- 必须打开提供给源命令的路径。
操作系统检查权限路径，解析符号链接。 这对于您的特定情况来说是次要的。 对于一些反复检查文件路径的应用程序来说，这可能是一个重大打击 （例如网络服务器）。 - 文件被读入。 磁盘 I/O。总是很慢。
- 文件被解析和解释。
解析总是很慢。
Tcl 有一个简单的规则集，所以它的解析可能比一些更快。 - 由于您的函数被替换... 这里的问题是字节码编译器现在忘记了任何优化 已经到位，并且该功能第一次运行时会比平时慢 它被使用了。
始终注意您的程序正在使用哪些资源（cpu、磁盘、内存、网络），并尽量减少使用量。
意见：您会发现人们只会说“获得更好的硬件”。这些人是傻瓜，这就是大多数网络如此缓慢的原因。他们不必要地浪费资源。
【讨论】：
看看你的核心问题：
package require比source快吗？
它们不能直接比较。
包是一个比脚本文件更高级别的概念，您可以source，并且通常由source 一个或几个文件实现。还有一个缓存机制，因此当您第一次执行package require 时，它肯定会比source 慢得多（因为包管理子系统需要搜索您拥有的包，如果它没有识别您要求的那个，实际上涉及在相当多的pkgIndex.tcl 文件上使用source）随后对package require 的调用可能更快，因为包没有加载两次。一旦构建了内部索引（通常每个解释器花费一次），已知但未加载包的package require 并不比直接sourceing 其实现文件慢多少。除了正在发生的“更高级别”的事情：该包可能根本无法由您可以source 实现的东西，而是可能使用 DLL 的load。或者它可以做一个混合。这就是包的业务：您通常需要知道的只是功能具有名称和版本。这与直接source 形成鲜明对比，您需要知道代码的确切位置（好吧，如果它位于已知的固定位置或相对于当前脚本的位置，这很容易），而且该文件正是您所需要的。一般来说，最好将策略（例如，package require foobar 1.2.3）与实施（例如，source -encoding utf8 /usr/local/lib/tcl/packages/foobar_1.2.3/foobar.tcl）分开。
包是一次性事物的一个结果是它们不是用于创建对象实例和类似对象的事物（API 中有效记录的单例除外） .您package require 获取构造命令（可能是类），然后使用这些命令在需要时创建所需的实例。
【讨论】：