在阅读了基于文件的PHP会话如何不是性能最佳之后,我想到了。这是否意味着包含大量文件的PHP脚本也不好?既然它包含一个文件,或者它与会话数据文件的检索方式不同?
答案 0 :(得分:6)
您应该使用spl_autoload_register()和OOP。这样,无论你的项目目前有多小,或者它随着时间的推移会有多大(并且排除这种可能性都是愚蠢的),PHP将只包括它所需要的,不多也不少。
这就是运行时RAM使用,代码的可维护性和硬盘延迟时间的影响之间完美的面向未来的平衡,我会说,只要你正确地模块化你的代码,当然(XDebug有帮助)。
话虽如此,它意味着包含未使用文件的不良。
由于php.ini指令include_path,无论采用哪种方式(spl_autoload_register()或其他方式),都应该使用绝对路径来包含文件。当使用相对路径时,PHP将搜索您的文件。
为什么“include'foo.php'”的一个小注意事项就像“include'./foo.php'”(包含文件的“正常”方式):这是因为目录“。”默认情况下是include_path的一部分。
答案 1 :(得分:2)
实际上并不是那么糟糕。这可以通过以下事实表明:没有人尝试创建编译器以使整个PHP应用程序成为单个脚本。
如果您实际使用PHP的microtime
函数来测量花费的时间,那么它将是十亿分之一秒。
答案 2 :(得分:2)
我认为每个摆弄PHP的人都会在他们的图书馆变得庞大的时候达到这一点,并且担心性能问题。
我的经验是,是的,如果你总是加载你的所有库,那么这将占用宝贵的内存(其中每个进程只分配一个固定数量的兆字节)。我有源代码文件,重量为300-400kb(带注释),每个脚本实例吃2-3 MB。看到一个脚本只有16-32 MB的许多共享主机,那就是 lot 。此外,每个请求的处理速度通常高达半秒,这太过分了。
因此,拆分是绝对必要的,并且很容易与Autoload和consorts一起使用。查看我对 this question 的回答,了解有关如何明智地拆分代码的一些建议。还有a question about how to organize a large PHP project的链接,取得了很好的效果。我自己正在弄清楚完美的结构,还没有完成。 :)
答案 3 :(得分:1)
就像Chacha102写的那样,它并不是那么糟糕。
但它还取决于您的实际脚本文件。
在实践中,您应该对自己的代码进行分析,Xdebug对此非常有用。
澄清:个人资料和比较。如果可以的话,避免使用大量的小脚本文件,但仍然保持源代码的有序性(编辑数千行的单个脚本不舒服)。分析器会给你一些数字以找到一个良好的平衡。
答案 4 :(得分:1)
就个人而言,我总是对页面处理的数据有更多问题,而不是源文件的大小和数量。但是,我在抽象层中编写了大量参数化代码(将其视为cut-n-paste编程的反面),因此仅通过改变半打简单参数就可以通过相同的代码完成许多不同的工作。
答案 5 :(得分:0)
包含大量小文件的效果不如包含大文件,这就是APC等缓存引擎存在的原因。
答案 6 :(得分:0)
另一种选择是“懒惰”包含文件,例如,在使用它们之前使用require_once(示例实例化一个类),这样就不会发生整个未使用包含的负载。
我已经使用了Zend功能(注册自动加载),但我不知道它是不是通用的php,或者它是否存在于其他框架中......