Live data from Hacker News

PHP "require" Performance

gazehawk.com

21–30 of 38 posts

Re: PHP "require" Performance

#21

Earlier quoted context omitted.

This article is a serious micro-optimization and, in general, not something people should be that worried about. If you nit-pick enough, all platforms have these sorts of issues.

In a good language, include/require[_once] should all be reduced to the same one statement, e.g. Python's import. Don't you think it's a ridiculous notion that the distinctions between include and require (and the once variants) are meaningful enough that programmers should be able to express them?

PHP using __autoload and namespaces looks and feels exactly like Python using imports. You see, the PHP developers have been actively improving a lot of aspects of the language recently, and the latest release, 5.3, had a ton of really nice improvements and features, such as namespaces.

I'm not going to say PHP is the greatest language every invented, and in fact I am a huge fan of Python. But I do not think PHP deserves the "In a good language..." treatment. It is a language that is getting better everyday, with a strong and vibrant development community and massive user adoption. It is a good language.

Re: PHP "require" Performance

#22

Earlier quoted context omitted.

In a good language, include/require[_once] should all be reduced to the same one statement, e.g. Python's import. Don't you think it's a ridiculous notion that the distinctions between include and require (and the once variants) are meaningful enough that programmers should be able to express them?

PHP using __autoload and namespaces looks and feels exactly like Python using imports. You see, the PHP developers have been actively improving a lot of aspects of the language recently, and the latest release, 5.3, had a ton of really nice improvements and features, such as namespaces. I'm not going to say PHP is the greatest language every invented, and in fact I am a huge fan of Python. But I do not think PHP dese…

amen. nobody chooses to use php on new projects but at least it's easy, fast, and pays the bills.

Re: PHP "require" Performance

#23
post #5

There should really be no reason why __autoload() should be significantly slower than require_once(). It's even trivially easy to ensure your classes are __autoloaded()'d from absolute paths to make opcode caches happy.

Even if autoload is slower, it's such a simple concept that even if you use it early on and need to take it out later, you wouldn't have to restructure anything. If you know performance is that big of a deal upfront, anything bug vanilla PHP might not be the best choice since the interpreter will probably become a bottleneck.

Re: PHP "require" Performance

#24
post #16

Every time I see an article like this I thank God I'm not using PHP. It's always, "Remember to always use do_something() instead of dosomething() or else something will suck for some reason."

"Remember to always use do_something() instead of dosomething() or else something will suck for some reason."

I'd say that is the case for any language.

Re: PHP "require" Performance

#25
post #22

Earlier quoted context omitted.

PHP using __autoload and namespaces looks and feels exactly like Python using imports. You see, the PHP developers have been actively improving a lot of aspects of the language recently, and the latest release, 5.3, had a ton of really nice improvements and features, such as namespaces. I'm not going to say PHP is the greatest language every invented, and in fact I am a huge fan of Python. But I do not think PHP dese…

amen. nobody chooses to use php on new projects but at least it's easy, fast, and pays the bills.

Really? I choose it every time I have a choice.

Especially with a Rails-like framework like CakePHP, I find that my programing time is lessened dramatically because of the framework, and my processing time is much lower than Rails because most of the servers I work on are optimized out the wazoo for PHP instead of Ruby.

But your mileage may vary.

Re: PHP "require" Performance

#26
post #16

Every time I see an article like this I thank God I'm not using PHP. It's always, "Remember to always use do_something() instead of dosomething() or else something will suck for some reason."

Really, every time I hear of PHP I honestly ask myself: "why on earth would anyone want to be using PHP in this day and age?"

It is like seeing people trying to cure cancer with leeches.

Re: PHP "require" Performance

#27

Always use Autoload if you can for large projects. The DRAMATIC performance losses of requiring files and classes you do not ever use during a page load can be pricey. Rasmus' quote was saying that PHP/APC can't save the opcode for a file WITH all of the includes if there is any conditional associated with the require. This means that each include's opcode will be pulled from cache each time (not a big deal!!!). [200…

I'm not sure #3 is really a benefit.

Re: PHP "require" Performance

#28

Keep in mind those numbers are microseconds. If you are looking for ways to improve your performance, there are probably lots of other places to focus your attention that will have a much greater impact. For example, optimizing your frontend will give you far more bang for the buck and in fact I'd argue that sometimes it's worth the extra 300 microseconds for the sanity of your development team.

I don't believe he provided units, since it was over a large number of runs, and the units would be relative and meaningless due to hardware and setup differences (he said as much in the comments, as well).

Re: PHP "require" Performance

#29

Earlier quoted context omitted.

This article is a serious micro-optimization and, in general, not something people should be that worried about. If you nit-pick enough, all platforms have these sorts of issues.

In a good language, include/require[_once] should all be reduced to the same one statement, e.g. Python's import. Don't you think it's a ridiculous notion that the distinctions between include and require (and the once variants) are meaningful enough that programmers should be able to express them?

Don't you think it's a ridiculous notion that the distinctions between include and require (and the once variants) are meaningful enough that programmers should be able to express them?

Not at all. They mean different things, and they're used for different things. Import-if-it's-available is include, import-or-error-if-missing is require, and they're both quite handy. The once variants do what most programmers would expect, but the non-once ones do what most template users would expect. Should the "once" have been a flag? Yeah, why not? But that doesn't mean the functionality shouldn't even exist.

Re: PHP "require" Performance

#30
post #5

There should really be no reason why __autoload() should be significantly slower than require_once(). It's even trivially easy to ensure your classes are __autoloaded()'d from absolute paths to make opcode caches happy.

My initial thought was "surely it's just a quick hash lookup", but then require_once is probably using the canonical path for that lookup, which involves calling realpath() or abspath(), at that point all bets are probably off, especially in a shared hosting environments involving things like NFS. Edit: I looked at the implementation. require_once/include_once unconditionally opens the file, whether it has been loade…

Ugh, you're bringing up bad memories for me. I was once bit badly by the require_once/realpath() problem.

require_once("/foo/bar/baz/random/crap/foo.php");

The above requires 5 lstat(2) system calls thanks to realpath() and a typical WordPress-MU page load for us was calling lstat over 5k times. Over NFS that's 5k round trips to the server for every page load. Thankfully there is a knob you can tune in PHP 5.1.x (realpath_cache_size) that caches all those lstats, but as usual, the default is (16K) is too small to be of any use.

Post reply on HN