CODEWITHSUNDEEP
phpperformanceincludeserver-side-includes
Average Joe
Average Joe

Reputation: 4601

include selectively or globally?

With this question, I aim to understand the inner workings of PHP a little better.

Assume that you got a 50K library. The library is loaded with a bunch of handy functions that you use here and there. Also assume that these functions are needed/used by say 10% of the pages of your site. But your home page definitely needs it.

Now, the question is... should you use a global include that points to this library - across the board - so that ALL the pages ( including the 90% that do not need the library ) will get it, or should you selectively add that include reference only on the pages you need?

Before answering this question, let me point "why" I ask this question...

When you include that reference, PHP may be caching it. So the performance hit I worry may be one time deal, as opposed to every time. Once that one time out of the way, subsequent loads may not be as bad as one might think. That's all because of the smart caching mechanisms that PHP deploys - which I do not have a deep knowledge of, hence the question...

Since the front page needs that library anyway, the argument could be why not keep that library warm and fresh in the memory and get it served across the board?

When answering this question, please approach the matter strictly from a caching/performance point of view, not from a convenience point of view just to avoid that the discussion shifts to a programming style and the do's and don'ts.

Thank you

Upvotes: 1

Views: 99

Answers (3)

AdamJonR
AdamJonR

Reputation: 4713

I very much appreciate your concerns about performance.

The short answer is that, for best performance, I'd probably conditionally include the file on only the pages that need it.

PHP's opcode caches will maintain both include files in a cached form, so you don't have to worry about keeping the cache "warm" as you might when using other types of caches. The cache will remain until there are memory limitations (not an issue with your 50K script), the source file is updated, you manually clear the cache, or the server is restarted.

That said, opcode (PHP bytecode) caching is only one part of the PHP parsing process. Every time a script is run, the bytecode is then processed to build up the functions, classes, objects, and other instance variables that are defined and optionally used within the script. This all adds up.

In this case, a simple change can lead to significant improvement in performance. Be green, every cycle counts :)

Upvotes: 1

ficuscr
ficuscr

Reputation: 7063

The caching I think you are referring to would be opcode caching from something like APC? All that does is prevent PHP from needing to interpret the source each time. You still take some hit for each include or require you are using. One paradigm is to scrap the procedural functions and use classes loaded via __autoload(). That makes for a simple use-on-demand strategy with large apps. Also agree with Will that you should measure this if you are concerned. Premature optimization never helps.

Upvotes: 1

Will Hartung
Will Hartung

Reputation: 118794

Measure it, then you know.

The caching benefit it likely marginal after the first hit, since the OS will cache it as well, but that save only the I/O hit (granted, this is not nothing). However, you will still incur the processing hit. If you include your 50K of code in to a "Hello World" page, you will still pay the CPU and memory penalty to load and parse that 50K of source, even if you do not execute any of it. That part of the processing will most likely not be cached in any way.

In general, CPU is extremely cheap today, so it may not be "worth saving". But that's why you need to actually measure it, so you can decide yourself.

Upvotes: 1

Related Questions