View Full Version : include pages & size vs. load
crobinson42
09-16-2012, 01:50 AM
Hello everybody, this might be a dumb question but i can't get an answer from google on this topic and i do not fully understand php.net explanation of this topic.
I have several different classes and i have created seperate files for most classes. I include them as needed. I am curious if I put all my classes on one page will that effect the speed of my site if i have several hundred users?
Thanks for any insight provided.
djr33
09-16-2012, 02:39 AM
Only the text output (HTML, CSS, JS, etc.) will cause any difference in transfer times (loading speed). But anything you add to a page can slow down the processing, and if you have a lot of users it will be multiplied by that much.
It really depends on the details, but the short answer is yes.
However, that's fairly standard and probably not something you should really worry about. Keeping things streamlined is a good idea, and one option is to create a loading function that will add in features as needed. For big projects, I've done this. So you'd have something like loadfunctions('functionset') and then you'd load it quickly that way. So if you need, for example the database on one page, but not on another, you could save time on that other page. But it's only worth it if this is a particularly big site, or specifically if there are a lot of functions being loaded.
The only way I know of to test this sort of thing is to run a loop (maybe 1000 times) of a simple operation (eg, including a page) and then timing that. It can simulate many users.
(Unfortunately, if you're including a page that defines functions, you'll get a fatal error if you include the page multiple times. Not sure what to suggest in this case.)
I include them as needed
meaning, you don't include them if they're not needed? :)
always including them, no matter what, would increase processing time in situations where the pages weren't actually needed.
crobinson42
09-16-2012, 05:04 AM
meaning, you don't include them if they're not needed?
Correct. I include the pages with the classes that i need as needed. My question is if I were to simply put all my classes in one file -would a file with 10 different classes cause slower load then calling the files individually for example if a page used 2 or 3 classes having 2 or 3 includes on the page.
djr33
09-16-2012, 05:16 AM
The actual processing load of the include() command is very very minimal, I imagine. And what it does is essentially tells the server to pretend that the contents of that page are inside the current page.
That is: if you have all of the classes in the main page, or if you include them all from one page, or if you include them separately from multiple pages, I think the processing times will be almost identical, certainly nothing that would ever become a practical issue-- you'll have bigger things to worry about before that is ever a problem.
So how you include the classes is probably entirely irrelevant; the question is whether you include them at all.
Scenarios:
1) You include all classes on every page:
--then every page will be slowed down (very slightly, probably not noticably on a small site) a little bit
2) You include only the classes you need on every page:
--then those pages that don't need a lot of classes will load every so slightly faster-- a little bit, theoretically faster, just not too important
I do think about these things when I'm designing a site and I usually include a shared base of functions for everything. But if there's a particularly complicated (=long) include, I'll try to limit that to the pages where it is actually needed.
There isn't really a standard answer for all of this. I suppose one area where you could run into problems is the memory on the server. If it's trying to serve a lot of people at one time and these classes are being stored in memory, it's possible you could run into the memory limits set in php.ini or by your host. That's only the case with really long classes, though.
Powered by vBulletin® Version 4.2.2 Copyright © 2021 vBulletin Solutions, Inc. All rights reserved.