我有一位同事正在为我们基于 PHP 的应用程序研究操作码缓存/Zend 加速（我一直认为它们是同一件事）。 他的基准似乎表明，如果我们使用 require_once 包含我们的（大型）类库，我们不会看到性能优势，但使用 include_once 时我们确实看到了性能优势。
这对我们俩来说都有腥味，但我自己没有时间检查我们的基准方法，而且我的同事对鱼味的容忍度比我高。 :)
有没有人遇到过这样的事情？ 如果没有，对其他可能导致通过从 include_once 切换到 require_once 来提高性能的事情有什么想法吗？
I have a colleague who is looking into opcode caching/Zend Acceleration (I've always assumed these are the same thing) for our PHP based application. His Benchmarks appear to indicate that we're NOT seeing a performance benefit if we include our (large) class libraries with require_once, but we DO see the performance benefit when using include_once.
This smells fishy to both of us, but I don't have time to check into our benchmark methodology myself and my colleague has more tolerance for the smell of fish than I do. :)
Has anyone ever run into anything like this? If not, any thoughts on other things that might be causing the appearance of a performance increase by switching from include_once to require_once?
发布评论
评论（2）
对于初学者来说，两个调用（require_once 和 include_once）都会仔细检查之前是否未包含文件。
因此，他们实现这一目标的方法是在所有可用路径中搜索文件，并本质上检查它是否之前没有混合过等等。
在后台发生的事情是他们评估所有不同的选项（例如多个 include_path 的等），然后通过从这个缩写形式创建真实路径，他们创建了一个唯一的标识符。 只有一条相同的路径，而不是两条。
这已经不是地球上最快的过程，并且通常在每个 PHP 请求上发生。 然后添加另一个昂贵的操作，即创建我所说的真实路径时的统计数据（真实路径，因为它类似于realpath() 会检查文件是否存在。
如果我错了，请纠正我，但 APC 特别针对这种情况进行了优化。
所以无论如何 - 现在来看看 require_once 和 include_once 之间的区别，即 require_once 在包含文件时评估文件（对于低级解析错误等）。 这是一项额外的检查，如果您有足够的 QA，解析错误永远不会潜入包含中，则可以取消该检查。
很难找到其他的。 :-)
（需要考虑的事情：您可以使用 require_once 进行开发，并在部署时用 include_once 替换所有调用。）
至于操作码缓存 - 我建议 APC。 之前在 stackoverflow 上讨论过。 就我个人而言，我/我们正在使用它一段时间（我们每天处理大约 10 万访客，有 3 个前端和 1 个后端），我们非常高兴。 APC 还针对 require_once/include_once 疯狂进行了优化。
一个非常酷的副作用是 APC 还允许您将 PHP 变量存储在内存中 - 有点持久化等。
一些额外的提示：
希望有帮助。
For starters, both calls (require_once and include_once) double-check if a file has not been included before.
So the way they both achieve this is by searching the file in all available paths and by essentially checking if it hasn't been in the mix before etc..
In the background what happens is that they evaluate all the different options (e.g. multiple include_path's, etc.) and then by creating the realpath from this abreviated form they create a unique identifier. There is only one and the same path - not two.
This is already not the fastest process on the planet and generally happens on each request with PHP. Then add another expensive operation which is the stat when it creates what I called the realpath (realpath, because it's sort of what realpath() does) to check if the file exists.
Correct me if I am wrong, but APC has optimizations especially for this case.
So anyway - now on to the difference between require_once and include_once, which is that require_once evaluates the file (for low-level parse errors, etc.) when it includes it. This is an additional check which you can get rid of if you have enough QA in place that a parse error can never sneak into an include.
It's just tricky to find otherwise. :-)
(Something to consider: You could develop with require_once and replace all calls with include_once when you deploy.)
As for an opcode cache - I'd recommend APC. It's been discussed on stackoverflow before. Personally, I am/we are using it for a while (we handle roughly 100k visitors/day with 3 frontends and 1 backend) and we are very happy. APC is also optimized for the require_once/include_once madness.
A pretty cool side-effect is that APC also allows you to store PHP variables in memory - sort of persistant, etc..
A couple additional pointers:
Hope that helps.
我不能保证任何事情，因为我还没有足够深入地研究它，但是，是的，我已经看到了两者之间的速度差异。 不过，它们对我来说从来没有重要到足以移动到 include_once 而不是 require_once 。
我一直认为差异是因为 require_once 必须在水下做更多的工作。 至少还有一个潜在的错误需要准备和处理，并且当所需的文件不存在时还有很多工作要做。
I can't guarantuee anything as i haven't looked deeply enough into it, but yes, i have seen speed differences between the two. They were never significant enough to me to move to include_once instead of require_once though.
I always assumed the difference was because require_once has to do more work underwater. at least one more potential error to prepare for and handle, and a lot more to do when the file required does not exist.