Live data from Hacker News

PHP "require" Performance

gazehawk.com

11–20 of 38 posts

Re: PHP "require" Performance

#11
I'm trying to understand the metrics here. Doesn't the first test show that _autoload is actually much faster than require or require_once?

require_once: 1579 require: 1318 __autoload: 578

The second test shows a similar result:

require_once: 1689 require: 1382 __autoload: 658

Am I missing something here?

Re: PHP "require" Performance

#12
post #10
post #7

Hmm, PHP 5.2+ is still that slow with require_once ? I thought they fixed that. Anyway, just use function_exists instead.

Yup, we're on 5.3. May have something to do with the relative vs. absolute paths (we use relative), but still... Turns out we didn't need require_once anyway, all but a couple of includes in our entire codebase were in that one area.

Out of curiosity, what does your include_path look like? Is ./ the first element, the last, or somewhere in the middle?

Re: PHP "require" Performance

#13
post #11

I'm trying to understand the metrics here. Doesn't the first test show that _autoload is actually much faster than require or require_once? require_once: 1579 require: 1318 __autoload: 578 The second test shows a similar result: require_once: 1689 require: 1382 __autoload: 658 Am I missing something here?

Yes, __autoload is much faster, because it only ends up loading ~5 of the files. Previously we had included 30 files by default, and even though __autoload is slower on a file-by-file basis, the savings on the files we didn't need to load at all made it very worthwhile.

Re: PHP "require" Performance

#14
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!!!). [2006, http://pooteeweet.org/blog/538/]

Things in favor of Autoload:

1) Ease-of-use of not worrying about if your class is available

2) If you don't use Autoloading and require clases, you have to load all of those from the opcode cache (and make APC keep track of them) despite that you may not be using many of those classes at all.

3) It helps encourage putting things in classes (whether they are static functions or not).

4) If you ever need to conditionally require a class, you are likely going to run into the same opcode cache hits (instead of NOPs) as Autoload. You'll have to include ALL of your classes to avoid the problem.

Re: PHP "require" Performance

#15
post #12
post #10

Earlier quoted context omitted.

Yup, we're on 5.3. May have something to do with the relative vs. absolute paths (we use relative), but still... Turns out we didn't need require_once anyway, all but a couple of includes in our entire codebase were in that one area.

Out of curiosity, what does your include_path look like? Is ./ the first element, the last, or somewhere in the middle?

. is the first entry

Re: PHP "require" Performance

#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."

Re: PHP "require" Performance

#17
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.

Re: PHP "require" Performance

#18
post #10
post #7

Hmm, PHP 5.2+ is still that slow with require_once ? I thought they fixed that. Anyway, just use function_exists instead.

Yup, we're on 5.3. May have something to do with the relative vs. absolute paths (we use relative), but still... Turns out we didn't need require_once anyway, all but a couple of includes in our entire codebase were in that one area.

As quickly as possible I turn relative paths to absolute paths (with __DIR__) to avoid any more overhead there. I also empty the include path; no need to have PHP searching for files all over the place.

Re: PHP "require" Performance

#19
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."

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.

Re: PHP "require" Performance

#20
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."

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?
Post reply on HN