缩小 PHP 有什么意义吗?

我知道你的 可以缩小 PHP,但我想知道是否有任何意义。PHP 是一个直译语言,所以运行速度会比编译语言慢一点。我的问题是: 如果我缩小我的 PHP,客户会看到页面加载速度的明显提高吗?

还有,是否有一种方法来编译 PHP 或类似的东西?

51462 次浏览

PHP is compiled into bytecode, which is then interpreted on top of something resembling a VM. Many other scripting languages follow the same general process, including Perl and Ruby. It's not really a traditional interpreted language like, say, BASIC.

There would be no effective speed increase if you attempted to "minify" the source. You would get a major increase by using a bytecode cache like APC.

Facebook introduced a compiler named HipHop that transforms PHP source into C++ code. Rasmus Lerdorf, one of the big PHP guys did a presentation for Digg earlier this year that covers the performance improvements given by HipHop. In short, it's not too much faster than optimizing code and using a bytecode cache. HipHop is overkill for the majority of users.

Facebook also recently unveiled HHVM, a new virtual machine based on their work making HipHop. It's still rather new and it's not clear if it will provide a major performance boost to the general public.

Just to make sure it's stated expressly, please read that presentation in full. It points out numerous ways to benchmark and profile code and identify bottlenecks using tools like xdebug and xhprof, also from Facebook.


2021 Update

HHVM diverged away from vanilla PHP a couple versions ago. PHP 7 and 8 bring a whole bunch of amazing performance improvements that have pretty much closed the gap. You now no longer need to do weird things to get better performance out of PHP!

Minifying PHP source code continues to be useless for performance reasons.

Forgo the idea of minifying PHP in favor of using an opcode cache, like PHP Accelerator, or APC.

Or something else like memcached

With some rewriting (shorter variable names) you could save a few bytes of memory, but that's also seldomly significant.

However I do design some of my applications in a way that allows to concatenate include scripts together. With php -w it can be compacted significantly, adding a little speed gain for script startup. On an opcode-enabled server this however only saves a few file mtime checks.

There are PHP compilers... see this previous question for a list; but (unless you're the size of Facebook or are targetting your application to run client-side) they're generally a lot more trouble than they're worth

Simple opcode caching will give you more benefit for the effort involved. Or profile your code to identify the bottlenecks, and then optimise it.

This is less an answer than an advertisement. I'm been working on a PHP extension that translates Zend opcodes to run on a VM with static typing. It doesn't accelerate arbitrary PHP code. It does allow you to write code that run way faster than what regular PHP allows. The key here is static typing. On a modern CPU, a dynamic language eats branch misprediction penalty left and right. Fact that PHP arrays are hash tables also imposes high cost: lot of branch mispredictions, inefficient use of cache, poor memory prefetching, and no SIMD optimization whatsoever. Branch misprediction and cache misses in particular are achilles' heel for today's processors. My little VM sidesteps those problem by using static types and C array instead of hash table. The result ends up running roughly ten times faster. This is using bytecode interpretation. The extension can optionally compile a function through gcc. In that case, you get two to five times more speed.

Here's the link for anyone interested:

https://github.com/chung-leong/qb/wiki

Again, the extension is not a general PHP accelerator. You have to write code specific for it.

You don't need to minify PHP. In order to get a better performance, install an Opcode cache; but the ideal solution would be to upgrade your PHP to the 5.5 version or above because the newer versions have an opcode cache by default called Zend Optimiser that is performing better than the other ones http://massivescale.blogspot.com/2013/06/php-55-zend-optimiser-opcache-vs-xcache.html.

Yes there is one (non-technical) point.

Your hoster can spy your code on his server. If you minify and uglify it, it is for spys more difficult to steal your ideas.

One reason for minifying and uglifying php may be spy-protection. I think uglyfing code should one step in an automatic deployment.

The "point" is to make the file smaller, because smaller files load faster than bigger files. Also, removing whitespace will make parsing a tiny bit faster since those characters don't need to be parsed out.

Will it be noticeable? Almost never, unless the file is huge and there's a big difference in size.