PHP中哪个性能更好？

我通常会在我的网站的hader中包含1个函数文件，现在这个网站的流量相当高，我只是想尽我所能把每一件小事都做到最好，所以我的问题是

---

包含多个较小的函数类型文件以及该页面所需的代码是否更好，还是将其全部加载为一个大文件并没有任何区别，我当前的函数文件具有整个站点的所有函数，大约4000行长，并加载到整个站点的每个页面上，那么糟糕吗？

一般来说，在文件管理方面，最好将内容分解成更小的文件，因为您只需要加载实际使用的文件。但是，在4000条线路上，可能不会有太大的区别

我建议一个类似的解决方案

function inc_lib($name)
{
    include("/path/to/lib".$name.".lib.php");
}

function inc_class($name)
{
    include("/path/to/lib".$name.".class.php");
}

---

我认为，如果您可以将函数文件拆分为适合每个页面的组件，那就更好了；并在相应页面中调用这些组件。就我的2美分

---

p/s：我是一名PHP业余爱好者，我正在尝试制作一个PHP网站；我没有使用任何函数。那么，你能告诉我一个站点需要什么功能吗？

根据我的经验，拥有一个到处都包含的大型包含文件实际上会降低性能。我曾在一个浏览器游戏中工作过，在这个游戏中，我们所有的游戏规则都是动态生成的PHP（除其他外），文件的重量约为500kib。它肯定会影响性能，我们考虑生成一个PHP扩展

---

然而，像往常一样，我想说的是，你应该做你现在正在做的事情，直到它成为一个性能问题，然后根据需要进行优化。

这很难说。4000行在文件解析领域并没有那么大。在代码管理方面，这已经开始变得笨拙，但如果将其分解为2个、5个或10个文件，并且页面只包含所需的少数文件，则不太可能看到可测量的性能差异（这是更好的编码实践，但这是另一个问题）。您读取的行数与解析器需要打开的文件数之间的差异似乎不够大，无法保证任何重要的内容。我最初的反应是，这可能不是一个你需要担心的问题

---

另一方面，我参与了一个企业级项目，其中一些操作有一个

include（）

树，通常扩展到数百个文件中。分析这些操作表明，

include（）

调用所花费的时间仅占10秒加载操作的2-3秒（这是PHP4）。

如果您可以在服务器上安装扩展，您应该看看（）。
顺便说一句，它是免费的；-）；但您必须是服务器管理员才能安装它；所以它通常不会在共享主机上提供

这就是所谓的“操作码缓存”

基本上，当调用PHP脚本时，会发生两件事：

• 脚本被“编译”成操作码
• 执行操作码

APC将操作码保存在RAM中；因此，文件不必在每次调用时重新编译——这对CPU负载和性能都是一件好事

要进一步回答这个问题，请执行以下操作：

• 说到表演，4000行就不算多了；打开任何大型应用程序/框架的几个文件，您将很快得到几千行
• 一个真正重要的要考虑的问题是可维护性：对于您和您的团队来说，什么更容易使用
• 加载许多小文件可能意味着许多系统调用，这很慢；但这些可能会被操作系统缓存。。。所以可能与无关
• 如果您执行的是一个数据库查询，那么这个查询（包括PHP服务器和DB服务器之间的网络往返）可能比解析几千行要花更多的时间；-）

  ---

如果加载一个4000行的文件并使用一个10行的函数，那么是的，我会说它效率低下。即使您使用了1000行组合的许多功能，它仍然是低效的

我的建议是将相关函数组合在一起，并将它们存储在单独的文件中。这样，如果一个页面只处理数据库函数，您可以只加载数据库函数文件/库

---

另一个将功能拆分的原因是可维护性。如果需要更改函数，则需要在monalitic include文件中找到它。你可能也有非常非常相似的功能，但你甚至没有意识到。按功能进行排序可以让您比较它们，去掉不需要的东西，或者将两个功能合并为一个通用功能。

大多数时候，光盘IO会杀死您的服务器，因此我认为从光盘中获取的文件越少越好。此外，如果可以安装APC，那么文件将被编译存储到内存中，这是一个巨大的成功。

但是请记住，这些4k行必须被解析并为每个页面访问运行。除非你有一些优化器在运行，它可以缓存编译过的字节码，但最后我看到这些东西是有成本的，所以除非你付钱，否则通常不会安装。是的，这是真的。但是，处理多个文件的磁盘搜索也有成本。如果你假设他把它分成10个文件，每个文件有400行，平均每个文件有4行，那么他只剩下1600行代码和4个文件。问题是解析的行数减少是否超过了增加的include（）开销。我假设这种差别会非常小。当然，唯一确定的方法是对其进行基准测试。不过，如果您处于那种优化级别，那么花在操作码缓存上的时间会更好。好的，如果我决定打破int，谢谢您的评论