How many include/reuire , and its effect on PHP script speed
Moderator: General Moderators
How many include/reuire , and its effect on PHP script speed
Hi friends,
Hmmm this time i have a practical question. Hmmmmm so far my php applications (mostly sites) had only few "includes" like two or three classes in each. Now in my new app im having a very nice complex object structure and will have about 6 classes. So i have to included them in each and every page. One class is written in one php file and each contains about 200 lines. Hmmm Now i need to know what will happen to the speed when we include so many include files to a page.
Now i know in other languages like Java "import" is something like "include/require" in php. Am i correct? In java or C# we call so many classes and libraries from import we call. Right, now i need to know is this system suitable for PHP. For all those PHP people comment how many complex and bulky classes you use in PHP. Hmmm... i know its hard to say how many lines of code is ok... I wont need that.. Will find it with experience. I want to know when we call lots of include files will it delay the scripts. Hmmm.... whats your thoughts?
Hmmm this time i have a practical question. Hmmmmm so far my php applications (mostly sites) had only few "includes" like two or three classes in each. Now in my new app im having a very nice complex object structure and will have about 6 classes. So i have to included them in each and every page. One class is written in one php file and each contains about 200 lines. Hmmm Now i need to know what will happen to the speed when we include so many include files to a page.
Now i know in other languages like Java "import" is something like "include/require" in php. Am i correct? In java or C# we call so many classes and libraries from import we call. Right, now i need to know is this system suitable for PHP. For all those PHP people comment how many complex and bulky classes you use in PHP. Hmmm... i know its hard to say how many lines of code is ok... I wont need that.. Will find it with experience. I want to know when we call lots of include files will it delay the scripts. Hmmm.... whats your thoughts?
I tend to go with the likes of Lerdorf and Schlossnagle (George) who recommend between 5 and 10 includes. I think the number they suggest are arbitrary and the important thing is to pick a number that works for your production environment. I'm even more conservative than Lerdorf (at 5 includes) because almost all of my clients are on shared servers - no opcode cache and constant load.Right, now i need to know is this system suitable for PHP. For all those PHP people comment how many complex and bulky classes you use in PHP. Hmmm... i know its hard to say how many lines of code is ok... I wont need that.. Will find it with experience. I want to know when we call lots of include files will it delay the scripts. Hmmm.... whats your thoughts?
From George Schlossnagle:
A reasonable number of includes is fine (and promotes good code organization), but 25, 50, 100+ will impose a real performance penalty.
You might want to look into __autoload() so you don't have to include files in a page where the file is never called.
I am not sure of how many files I include, but with Zend Framework and my project I have many hundreds of class files. I am thinking its gotta be at least 50 files getting included on every page load. I have yet to see a big performance hit with that many even under load.
I am not sure of how many files I include, but with Zend Framework and my project I have many hundreds of class files. I am thinking its gotta be at least 50 files getting included on every page load. I have yet to see a big performance hit with that many even under load.
Re: How many include/reuire , and its effect on PHP script s
A project I have been working on, Phaux, has almost 300 files. Performance is not a problem. If performance becomes a problem you might want to look at installing an opt-code cacher, like APC. In fact on a production server I highly recommend installing APC even if you are not seeing any performance problems.
Like I said to you in a different thread. Don't worry about performance until you start to see issues. Focus on clean, simple, and modular design. If your design is clear and simple performance bottlenecks will be easy to locate and fix.
Like I said to you in a different thread. Don't worry about performance until you start to see issues. Focus on clean, simple, and modular design. If your design is clear and simple performance bottlenecks will be easy to locate and fix.
Yeah, don't get into pre-optimisation. Design what you need with as many files as you need. As long as the logic is clear, and your coding is clear, when a situation DOES arise, you'll be able to locate it pretty quickly.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
The real point in questions like this niro121 is: do you have a performance problem. If you do not then do not let hypothetical performance problems influence your design. Six files of 200 lines sounds like you are on the right track. I occasionally check my sites to see how many includes they use and it is usually around 15, but that is using a controller framework.
(#10850)
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
Afaik, in the first presentation i found by mentionned Schlossnagle i read the following:
Which, to me, seems an acknowledgment that caring about their number, could be premature optimization...Control your include trees to no more than 10 includes.
(Yes, that number is made-up.)
I find it interesting that they are written off so easily. Personally, for their work on PHP, APC, and some really large websites, I'm will to believe Lerdorf and Schlossnagle know what they're talking about when it comes to includes. They work on PHP and APC and I would think they know something of the inner workings of these and have the experience of using them in really large projects. I'm also sure they know what is premature optimization, Schlossnagle, in the link you provided, speak of premature optimization twice.timvw wrote:Afaik, in the first presentation i found by mentionned Schlossnagle i read the following:
Which, to me, seems an acknowledgment that caring about their number, could be premature optimization...Control your include trees to no more than 10 includes.
(Yes, that number is made-up.)
I don't think anyone is writing them off. If you work for Yahoo and your application gets millions of hits a day then having a small number of includes might help the performance of your application by a few microseconds. But way sacrifice code reusability, modularity, ease of development, design, and good practice for a few milliseconds on an application that does not gain much from the speed improvement.Arawn wrote:
I find it interesting that they are written off so easily.
The linked to slides even point out how most applications are database bound anyway and improving 10% of your code by %20 is likely going to make no real improvement at all. Even if you have thousands of includes your database performance is likely to be three or four times worse than your application performance.
All of this is moot anyway. It would be trivial to create a deployment script that compresses thousands of include files into a handful of files but I would never want to develop the application that way. (Class Foobar is in file A-H.php on line 3,468 ... Yikes!!).
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I don't think the people were written off, it was it OP basing a specific number of includes on comments where the author gave an obvious caveat. Also that comment was from 2005 and there have been some improvements in the performance of includes since then (which was the basis of Schlossnagle's concern about includes).Arawn wrote:I find it interesting that they are written off so easily. Personally, for their work on PHP, APC, and some really large websites, I'm will to believe Lerdorf and Schlossnagle know what they're talking about when it comes to includes. They work on PHP and APC and I would think they know something of the inner workings of these and have the experience of using them in really large projects. I'm also sure they know what is premature optimization, Schlossnagle, in the link you provided, speak of premature optimization twice.
I also think that Schlossnagle was hinting at some psychology here. I also use the 5-10 includes rule -- but my applications actually use around 15. That's not a failure on my part. The rule keeps me pushing to remove unnecessary includes. But I am not so foolish to hold the line on numbers that are "made up."
(#10850)
As others already posted: It was not my intention to write someone off...
What it (imho) really comes down to is the following: Include as much as you have to... (not more, and certainly not less)
I'd rather have 5 includes, because all my scripts are rather small, and only contain what is absolutely necessary than one giant script that contains 500k with functions that i won't use anyway... (Btw, once you have an opcode cache, tip#1 in the article i referred to, you don't need the parsing, and thus the including, anymore
)
If after a while i have performance problems and testing points out that the largest improvements can be gained by reducing the number of includes, i won't doubt a second to deploy single file that contains all the code in the production environment. (I think i'd still keep the separate files for development though)
What it (imho) really comes down to is the following: Include as much as you have to... (not more, and certainly not less)
I'd rather have 5 includes, because all my scripts are rather small, and only contain what is absolutely necessary than one giant script that contains 500k with functions that i won't use anyway... (Btw, once you have an opcode cache, tip#1 in the article i referred to, you don't need the parsing, and thus the including, anymore
If after a while i have performance problems and testing points out that the largest improvements can be gained by reducing the number of includes, i won't doubt a second to deploy single file that contains all the code in the production environment. (I think i'd still keep the separate files for development though)