Page 1 of 1

Performance - including functions

Posted: Mon May 16, 2005 5:56 am
by vigge89
As I come closer to finishing my CMS, I've became more intresting in performance questions relating to inclusion of big "function libraries". What I want to know is, does separating different function "types" (content, post, visitor, statistic handling, etc.) into a number of files and then including most of them even when just a few of them are needed affect performance and speed in PHP? I'm very concerned about this subject, as I want my CMS to be as optimized as possible. "Categorizing" functions into different files makes managing them much easier, which is great, but does it make the whole system slow?

Also, if anyone has any recommendations regarding how I should construct/design my CMS backend-wise, I'd be more than happy if you could post them :)

Thanks in advance // vigge

Posted: Mon May 16, 2005 6:43 am
by John Cartwright
I can't quite get into this right now but
What I want to know is, does separating different function "types" (content, post, visitor, statistic handling, etc.) into a number of files and then including most of them even when just a few of them are needed affect performance and speed in PHP? I'm very concerned about this subject, as I want my CMS to be as optimized as possible
Ideally, you would want to seperate your dissimilar functions as much as possible. Here is an example I can think of,

instead of having a user.php which will handle logging in and logging out, you could seperate the two functions have only call whichever one is needed. A lot of larger applications generally do this to minimize page call times.

I believe Roja mentioned something along these lines about one of his webgames so hopefully he will be able to shed some light :wink:

Posted: Mon May 16, 2005 7:44 am
by malcolmboston
from a purely "design" POV, i think splitting the functions up into different files for session handling, standard content etc is a much better way just because it doesnt look like a complete mess of 100's - 1000's (in my cases anyway) of function definitions.

also i have started to do this to my app's as i now employ a module system, basically i can clip in extra functionality from different files which interact with each other all in a nice interface

Code: Select all

if (file_exists("session_functions.php"))
{
  // it exists
  // appear as an available module
}

Posted: Mon May 16, 2005 8:47 am
by Buddha443556
I use a PERL script to build my files. PERL processes each file (html, php, css, whatever) looking for tags containing actual PERL commands to be evaluated. For example:

Code: Select all

<perl getsnippet('snippets/php_login.txt); >
The above example would insert my php login function into a file when it's built. No need for including function libraries, every page has exactly the functions and/or class/methods it's needs. No more, no less.

Don't get me wrong I still use includes for initialization, finalization and some classes and libraries. Using PERL to build my scripts just gives me more flexibility.

Maybe such a system could help you?

Posted: Mon May 16, 2005 8:52 am
by malcolmboston
i would not trust a script to organise my functions, that sort of thing in my opinion needs a human brain

Posted: Mon May 16, 2005 9:02 am
by Roja
Jcart wrote:
What I want to know is, does separating different function "types" (content, post, visitor, statistic handling, etc.) into a number of files and then including most of them even when just a few of them are needed affect performance and speed in PHP? I'm very concerned about this subject, as I want my CMS to be as optimized as possible
I believe Roja mentioned something along these lines about one of his webgames so hopefully he will be able to shed some light :wink:
Glad to.

As a general statement, the amount of load time generated by including N files is fairly trivial.

However, thats not to say you should immediately include a bazillion files, and damn the torpedos.

What I always suggest is benchmarking before changing. Run a benchmark on the large version of the file. Then split it up, save it as different (seperated) files, include those instead, and benchmark it.

Compare the results. Of course, you need to keep an eye on more than just page-gen time. Watch page response time (page gen time does a poor job of catching include speed differences, in my experience). Also watch server load, memory used, etc.

You may find that it decreases memory used, but increases server load. Or the opposite.

Each chunk of code is definitely unique. In part of TKI (a game I code), I include over a dozen files with less than a 1% impact across the board. However, in the same game, in another part of the game, I include just *four* files, and take a whopping 17% hit in performance.

Its all about whats being included, and what your goals are. A 1,000+ line file may use less memory than including 10 seperate 100 line files, but may take longer (more file operations).

But to generalize, as a guideline, it seems that 3-4 files and around 0-500 lines are the sweet spot between maintainability, speed, and optimal loading patterns.

Of course, we are talking about functions. I have a completely different experience with Classes, as it seems that the impact from class files is lower than the impact from files full of functions. That may just be due to a small sample size, your mileage may vary, but it was interesting to me.

I feel compelled to edit and update.. It should be noted that others are far better at the "design" phase than I, so you may hear other opinions expressing an emphasis on OOP, which I don't disagree with in general. I was just answering the direct question. :)

Posted: Mon May 16, 2005 9:09 am
by Buddha443556
malcolmboston wrote:i would not trust a script to organise my functions, that sort of thing in my opinion needs a human brain
Neither do I, PERL is just processing the commands I give it.

Posted: Mon May 16, 2005 10:07 am
by onion2k
PHP caches a copy of the compiled script until one of the files it accesses changes, so you could include loads of completely unnecessary code and it'd make no difference to the execution speed after the first time it's run.

Posted: Mon May 16, 2005 10:41 am
by Buddha443556
onion2k wrote:PHP caches a copy of the compiled script until one of the files it accesses changes, so you could include loads of completely unnecessary code and it'd make no difference to the execution speed after the first time it's run.
Hmm...since when? I know you can install a compile cache like APC or Zend but what version of PHP started doing this?

Most hard drives have a cache which will help with include files though on a shared server they can fill up rather quickly. Compiling isn't really the bottleneck, it's the harddrive. PHP is really very fast, it's usually the hardware that's slow.

Posted: Mon May 16, 2005 11:46 am
by Roja
onion2k wrote:PHP caches a copy of the compiled script until one of the files it accesses changes, so you could include loads of completely unnecessary code and it'd make no difference to the execution speed after the first time it's run.
I'll echo Buddha's question.. what version of PHP does that?

Thats the exclusive territory of compile&cache programs like mmcache, APC, Zend, (and if you wanna go a little farther, Smarty).

Got a link for that functionality?

Posted: Mon May 16, 2005 5:45 pm
by McGruff
I'd second Roja's comments about benchmarking. Apache ab and Xdebug are important tools for this. You can waste a lot of time trying to squeeze milliseconds out of an app which frankly don't matter and benchmarking will help you to get a feel for what is worthwhile and what isn't. Wait till you're done writing: premature optimisation is the root of all evil.

Opcode compiling is a significant part of the total execution time - maybe up to half (Xdebug can provide report on this). So the less code you include, the better. If you're using a script cache it doesn't matter.

As a rough guide, the time I'd expect to spend on various areas would be something like:

design/testing: 90%
optimisation: 10%

It's just not something I expect to get much out of - but also not something to be ignored completely.

Posted: Tue May 17, 2005 8:52 am
by vigge89
Thanks alot for all the replies :)
I'll have a look at Apache ab and Xdebug soon, will probably be very intresting ;)

I've always thought that more code always equals to longer loading times, so thanks for pointing it out that I'm wrong :)

Posted: Tue May 17, 2005 9:14 am
by malcolmboston
i have just read this, wasnt even looking for it, not an exact quote but stats are the same
some web page wrote: PHP is a very fast parser, it can parse 100,000 lines of code on an 800mhz machine in around 3 seconds
Hope that answers some of your questions.

The site said that the only real reason you should chop up the functions intop different files, is, as i said, usability

Posted: Tue May 17, 2005 10:23 am
by Buddha443556
vigge89 wrote:I'll have a look at Apache ab ...
Might want to check out JMeter if your using shared hosting. CAUTION: You can whack the heck out of a shared server with JMeter. Shared servers are at load or over load so the there's no need to produce a traffic load. You just need to measure you scripts performance. Test accordingly.

Tip for CMS: Compare test results against static rendering of your dynamic page. That will gives you a benchmark. If I think can cut the number in half then I optimize. Otherwise there are better things to be doing.

Personally I use JMeter to test server/network performance more than my scripts. Some hosts are better than others, JMeter will give you the numbers to prove it.