我曾经使用过程式PHP。后来,我曾经创建过一些类。后来,我学习了Zend Framework并开始以OOP风格编程。现在我的程序基于我自己的框架(包含cms的元素,但在框架中没有任何设计),它建立在Zend框架的顶部。
现在它由很多课程组成。但是我编程的越多,我就越害怕。我担心我的程序会因为它们而变慢我害怕每增加一个可以帮助我开发但可以减慢应用程序的类。
我所知道的是,包含大量文件会降低应用程序的速度(使用eAccelerator +在一个文件中收集所有代码可以加速应用程序20次!),但我不知道创建新类和对象是否会减慢PHP本身的速度。
有没有人有任何相关信息?
答案 0 :(得分:37)
这让我烦恼。请参阅...程序代码并不总是意大利面条代码,但OOP粉丝总是假定它是。我已经编写了几个基于程序的Web应用程序以及PHP中的IRC服务守护程序。令人惊讶的是,它似乎胜过大多数其他的,编辑它是非常容易的。我的一个朋友一般都是OOP看过它并且说'#34;没有代码有权利这个干净"
一个优秀的程序员可以编写出色的过程代码而不需要开销类。一个糟糕的程序员总是编写糟糕的OOP代码来减慢速度。
没有一个正确的答案,哪个更好的PHP
答案 1 :(得分:18)
这里是good article discussing the issue.我也看到一些anecdotal bench-marks会将OOP PHP开销提高到10-15% 就个人而言,我认为OOP是更好的选择,因为最终它可能表现更好,因为它可能是更好的设计和思考。程序代码往往很混乱,难以维护。所以最后 - 它必须对你的应用程序的性能差异与维护,扩展和简单理解的能力有多重要
答案 2 :(得分:12)
最重要的是要记住,先设计,然后再进行优化。更好的设计,更易于维护,比意大利面条代码更好。否则,您也可以在汇编程序中编写Web应用程序。完成后,您可以分析(而不是猜测),并优化看起来最慢的东西。
答案 3 :(得分:2)
是的,每个include都会让你的程序变慢,但还有更多。
如果你通过许多文件分解程序,那么你可以包含/解析/执行最少量的代码,而不是包含所有这些文件的开销。
此外,拥有大量代码很少的文件并不是那么糟糕,因为正如你所说的那样,使用像eAccelerator或APC这样的东西是一种琐碎的方式来获得大量的性能。与此同时,如果您相信它们,您将获得具有面向对象代码库的所有好处。
此外,基于每个请求速度慢!=不可扩展。
<强>更新强>
根据要求,PHP在直接数组操作方面仍然比类更快。我依旧记得ORM项目的学说,有人比较了数组与对象的水合作用,并且数组出来的速度更快。然而,这不是一个数量级,而是显而易见的 - this is in french, but the code and results are completely understandable.。只是一个注释,该学说使用魔法方法__get和__set很多,而且这些方法也比显式变量访问慢,部分教条的对象水化缓慢可归因于此,所以我会将其视为最坏的情况。最后,即使你正在使用数组,如果你必须在内存中进行大量的移动,或者进行大量的测试,例如isset,或者像'in_array'这样的函数(它的顺序为N),你就会搞砸性能好处。还要记住,对象只是下面的数组,解释器只是将它们视为特殊的。我个人会赞成更好的代码,而不是小的性能提升,你可以通过更智能的算法获得更多的好处。
答案 4 :(得分:1)
如果您的项目包含许多文件,并且由于PHP的文件访问检查和限制的性质,我建议打开realpath_cache
,将配置设置提升到合理的数字,然后关闭{{1 }和open_basedir
。确保使用PHP-FPM或SuExec在用户标识下运行php进程,该用户标识仅限于文档根目录,以获取通常从safe_mode
和/或open_basedir
获得的安全性。
以下是一些为什么这是性能提升的指示:
还要考虑我对@Ólafur答案的评论:
我发现特别是自动加载是最大的减速。 PHP对目录查找和文件打开访问速度极慢,在自定义自动加载器中使用的PHP函数越多,减速越大。您可以通过关闭安全模式(不管怎样已弃用)甚至开放式(但我不会这样做)来帮助它,但最大的改进来自于不使用自动加载而只需使用带有完整fs的“require_once” pathes要求您使用的每个php文件的所有依赖项。
答案 5 :(得分:0)
如果您正在使用include_once(),那么无论是否设计OOP,都会导致不必要的减速。
OOP会为你的代码增加一些开销,但我敢打赌,你永远不会注意到它。
答案 6 :(得分:0)
您可能会重新考虑重新考虑您的课程结构以及如何实施它们。如果你说OOP较慢,你可能需要重新设计你的类,你如何实现它们。类只是对象的模板,任何设计不良的方法都会影响该类的所有对象。
尽可能使用继承和polimorfism,这将有效地减少您的类所需的行为和独立方法的数量,但首先需要创建一个良好的继承映射,抽象您的第一个或母亲类,就像您一样可以。
关于你有多少个类不是问题,问题是它们有多少方法,属性或字段以及这些方法的结构如何。继承减少了戏剧性设计方法的数量以及要编译的代码量。
答案 7 :(得分:0)
对于实际上不需要大量类的Web应用程序使用大型框架可能是许多人都不知道的最严重的问题。剥掉它至少不包括所有代码,保留你需要的东西并抛弃其余部分。
答案 8 :(得分:0)
正如其他几个人所指出的那样,OO PHP有一个轻微的开销,但你可以通过将优化工作集中在各种其他类派生的核心类上来抵消它。这就是为什么C ++在高性能计算领域越来越受欢迎,传统上是C和Fortran的领域。
就个人而言,我从未见过受CPU限制的PHP服务器。检查你的RAM使用情况(你也可以为此优化核心类)并确保你没有进行不必要的数据库调用,这比你正在进行的任何额外的CPU工作都要贵几个数量级。
答案 9 :(得分:0)
如果你设计了一个巨大的OOP对象,它可以做所有事情,而不是对各种类进行功能分解,你显然会用无用的镇流器代码填满内存。此外,使用缓慢的框架,你不会快速做一个简单的问候世界。我注意到这是一种趋势(坏习惯),对于一个单独的facebook图标,人们包括一个孔真棒字体库,然后接下来有一个包含fontello的搜索图标。每次他们完成不寻常的事情,他们就会连接整个框架。如果你想创建一个快速加载oop应用程序,只使用一个框架,如zephir-phalcon或任何你想要的并坚持下去。
答案 10 :(得分:-1)
有一些方法可以限制include_once条目的惩罚,并且通过在'include_once'文件中声明的函数本身在'include'语句中包含它们的代码内容。这将加载您的代码库,但只有那些实际使用的函数才会在需要时加载代码。您为包含的代码选择了第二个文件系统命令,但是内存使用几乎没有任何内容,只有程序使用的代码才会被加载。可以通过缓存来缓解来自第二文件系统访问的命中。在处理基于过程的PHP的大型项目时,这提供了低内存使用和快速处理。不要在课堂上这样做。这将是一个生产实例,开发服务器将显示所有点击的惩罚,因为您不希望打开缓存。