静态编译 php pecl 扩展（在二进制文件中 vs.extension=ext.so 中）是否可以提高性能？
在 php 二进制文件中编译 pecl 扩展是否会提高性能？
我希望我的术语是正确的，但是：
http://php.net/manual/ en/install.pecl.static.php
这就是我的意思。
我们有一小部分扩展，几乎在每个脚本执行中都会使用它们，并且我们认为将它们放在 mod_php 二进制文件中而不是通过 extension=ext.so @ php.d / php.ini 加载会更明智。此外，我们确实使用自编译的 php 二进制文件，而不是基于包（rpm/dpg/等）的二进制文件。所以这样做是相当微不足道的。
有人吗？
谢谢！
does compiling pecl extensions inside the php binary improve performance?
i hope my terminology is right, but:
http://php.net/manual/en/install.pecl.static.php
thats what i mean.
we have a small set of extensions that are used in pretty much every script execution and were thinking it would just be wiser to have them inside the mod_php binary rather then loaded via extension=ext.so @ php.d / php.ini. further more we do use a self-compiled php binary rather then a package (rpm/dpg/etc) based one. so doing this would be fairly trivial.
anyone?
thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不。
即使对于老式的 CGI，我也希望动态链接的版本会稍微快一些 - 假设您有连续的请求流 - 解释器的新实例将得到 COWed。静态链接方法唯一会更快（并且只是减少延迟）的情况是内存中没有实例。
OTOH 对于 fastCGI / 模块，代码只是分叉 - 它永远不会超出内存。
但是，无论如何，差异是如此之小，不值得考虑（放弃 CGI 将带来更多的性能改进）
No.
Even for old fashioned CGI, I'd expect that the dynamically linked version would be very slightly faster - assuming that you've got a continuous stream of requests - new instances of the interpreter would get COWed. The only time the statically linked approach would be faster (and then its just reducing latency) would be if there are no instances in memory.
OTOH for fastCGI / module, the code just forks - it never goes out of memory.
But, regardless, the difference would be so small its not worth considering (switching away from CGI would give massively more performance improvements)