PHP 中“包含”的性能成本是多少？

基本上，包含一个大文件的成本取决于您的使用案例。假设您有一个包含 200 个类的大文件。

如果只使用 1 个类，则包含大文件将比包含该单个类的小类文件更昂贵。

如果使用所有 200 个类，则包含大文件将比包含 200 个小文件的成本低得多。

截止点所在的位置实际上取决于系统。我想象它会在50%左右（如果你在任何一个请求中使用少于100个类，自动加载）。

使用APC可能会将盈亏平衡点移近到更少的类（所以如果没有，使用的100个类可能是盈亏平衡点，但它可能是使用50个类），因为它使大型单一包含便宜得多，但只会稍微降低每个单独的较小包含的开销。

确切的盈亏平衡点将100%取决于系统（磁盘I / O的速度，处理器的速度，内存量等）。因此，在您的平台上确定的唯一方法是进行测试。

然而，比原始性能更利害攸关。一个大文件的可维护性将受到影响，因为同时处理多个类会更加困难（IDE中的选项卡变得无用）。我个人会将所有类保存在单独的文件中，使我作为开发人员的生活更轻松，而不是使文件成为一个巨大的怪物。

现在，如果您有Facebook流量水平，则可能值得进一步调查。但如果你不是，我个人不会担心它...

我对php的各种成本进行了一些测试，我想分享这些测试，因为我看到许多程序员或CMS平台忽略了这些运行时前的php成本。include()

函数本身的成本可以忽略不计。100个文件包括（有空文件）成本约5ms;并且使用 opcache 时不超过一微秒。

因此，包含包含100个类的较大php文件的成本节省，而不是100个单独的文件包含，只有大约5ms。使用OpCode缓存使成本变得无关紧要。

真正的成本取决于文件的大小，以及PHP必须解析和/或编译的内容。为了更好地了解这些成本，以下是我在2010 Mac Mini Server上进行的测试结果，该服务器具有10，000 RPM驱动器，运行PHP 5.3，并启用了优化器的eAccelerator opcache。

1µs  for 100 EMPTY File includes, w/opcache
5ms  for 100 EMPTY File includes, no opcache

7ms   for 100 32KB File includes, w/opcache
30ms  for 100 32KB File includes, no opcache

14ms  for 100 64KB File includes, w/opcache
60ms  for 100 64KB File includes, no opcache

22ms  for 100 128KB File includes, w/opcache
100ms for 100 128KB File includes, no opcache

38ms  for 100 200KB File includes, w/opcache
170ms for 100 200KB File includes, no opcache

因此，一个600KB的php文件大约需要6毫秒，或者使用操作码缓存时大约需要1毫秒。相反，您真正想要关注的是每个请求包含的所有代码的大小。

在组合中合并文件以尝试节省资源绝对不是一个好主意，并且在使用操作缓存时会是一个错误。我的测试并没有考虑磁盘速度，因为我包含同一文件100次。也就是说，我根本不觉得需要覆盖磁盘I / O，因为安装op-cache确实是基本性能的先决条件。

为了尽可能地获得性能并节省RAM使用量，必须做相反的事情。这是通过使用自动加载程序或类工厂模式，尽可能多地在上下文中拆分文件，以便为每个请求包含尽可能少的未使用代码。

为此，滥用include_once（）也可能产生负面的性能后果...

关于您的基类。我有类似的情况，但我只包括表架构的一小部分。主要是字段类型和主键详细信息。出于性能原因，我故意不一直包含表的相当繁重的架构，因为它们很少使用，而当它们被使用时，我每个请求最多只使用其中的几个。

表的平均完整列详细信息大约为每个架构数组 20-50k。在任何给定的请求上包括10-15个阵列的成本仅为1-3毫秒。这本身并不多。但是，当与每个请求节省500k RAM相结合时，它就变得值得。