I have one big PHP code divided into multiple files, each one is loaded with require (exactly one time for each).
I'm curious if it's faster to have one big .php file with the whole code or different parts in different files (each part is always used).
Let's say one thousand people are refreshing the page, how much does the number of files (the code is divided in) change the speed? Which way is faster and why (what does it depend on)?
Thanks for any advice.
It terms of processing it really doesn't make a difference, requiring is like copy/pasting the file into the file your requiring it from.
It also keeps your code more organised.
EDIT:
since the require function uses include path it will be slightly slower, but not noticeably even with 100000000's of viewers refreshing.
Related
I'm creating a dashboard which will have different pages for different purposes. I'm thinking if wether I should have one PHP file for each page or one for all the pages?
Pros to me is:
One file with all functions to simplify work (less files - less clutter)
Cons:
Longer loading time because one large file?
I guess my major question is if there really is a major advantage/disadvantage to either?
Using a building irony, nobody says we can't pile 50 rooms one above another instead of spreading 25 on two levels!
1) Putting all files in one file is less clutter indeed, but more likely to break everything once something goes wrong at some point.
2) Depending on how many files you have to create, I would advise to separate functionality in multiple files. If one breaks, others may still work.
3) I love Ajax in that it can reduce all this "clutter issue", keeping in mind though, that everything will rely on your Ajax function being well done and securely put together
:)
I have a php file to handle a big amount of MySQL queries for my site and I'm expecting about hundreds to thousands users using it at a time. Will it make difference for the server reaction speed if I keep all these functions as a single file, or should I split them?
If you have a highly frequented web page, you should organize your code perfectly, because it seems to be more than a guestbook page - otherwise, the project runs out of your control. So put each function into its own file!
Only your second thought should be about performance. You could think about using opcode cache or other improvements like a static-map autoloader, a build script, that merges your php files and stuff.
But don't start to ruin your project's source code with this bad style.
Splitting functions into different files more better than writing all functions in one file
it's make including files more faster and best performance .... because you include only functions you want also you save server memory .
Also it's make you code more readable .
I have about 10 dynamic php pages which use about 30 functions. Each function is needed in more than 1 page, and every page needs a different subset of functions.
I've been pondering these options:
1- all functions in a single include file: every page loads unneeded code
2- each function in its own include file: too many server requests when loading each page
3 - single include file with conditionals only declaring functions needed based on REQUEST_URI: additional processing when loading each page
4 - one include file per php page, with copies of functions needed by that page: difficult to maintain
How does people handle this scenario? Thanks!
Option 1 is the simplest, the easiest to maintain, and probably quicker to run than options 2 and 3. Option 4 would be very very slightly faster to run, at the cost of being a maintenance nightmare.
Stick with option 1.
throw related functions into a library include. include libraries as needed.
Further, if you spend another 5 seconds thinking about this, that will be 5 additional seconds you've wasted
(In case you don't get what I'm saying, worrying about include optimization is about the 5billionth thing on your list of things you should ever worry about, until such time as a reported performance problem from end users and subsequent profiling tells you otherwise.)
You problem shouts OOP.
Organize code by Classes. Load Classes as needed.
More into PHP OOP.
The impact on your server of loading up 30 functions is despicable compared to the impact of yourself having to maintain a map and possible links to all 30 functions.
Start by putting them all in one include_once'ed file.
If performance becomes an issue, start by installing a PHP accelerator (to cache the parsed PHP into opcodes, so constant re-parsing is avoided) on the server.
When maintenance becomes an issue, break them up by function. You'll still end up with a catch-all "util.inc" or "misc.inc" file, though...
I have about 20 files containing 10-15 times this:
define('someConstantName','stringBetween10and200Chars');
those are all critical for the app, but each constants-file is parallel to an app page.
For example, index.php will require index_constants.php so on so forth.
The question is, should I make one file of all constant-definitions together, or require different files relatively to the pages they belong to.
I'm asking in terms of speed and efficiency.
Thanks.
If you are looking for the performance (since a file with useless data will be included whereas the page needs only one) then put a single file for each page but if you looking for ease/simplicity then you can put them in a single file (if you think it will not create any sort of complexity for you). Thanks...
I generally include 1 functions file into the hader of my site, now this site is pretty high traffic and I just like to make every little thing the best that I can, so my question here is,
Is it better to include multiple smaller function type files with just the code that's needed for that page or does it really make no difference to just load it all as 1 big file, my current functions file has all the functions for my whole site, it's about 4,000 lines long and is loaded on every single page load sitewide, is that bad?
It's difficult to say. 4,000 lines isn't that large in the realms of file parsing. In terms of code management, that's starting to get on the unwieldy side, but you're not likely to see much of a measurable performance difference by breaking it up into 2, 5 or 10 files, and having pages include only the few they need (it's better coding practice, but that's a separate issue). Your differential in number-of-lines read vs. number-of-files that the parser needs to open doesn't seem large enough to warrant anything significant. My initial reaction is that this is probably not an issue you need to worry about.
On the opposite side of the coin, I worked on an enterprise-level project where some operations had an include() tree that often extended into the hundreds of files. Profiling these operations indicated that the time taken by the include() calls alone made up 2-3 seconds of a 10 second load operation (this was PHP4).
If you can install extensions on your server, you should take a look at APC (see also).
It is free, by the way ;-) ; but you must be admin of your server to install it ; so it's generally not provided on shared hosting...
It is what is called an "opcode cache".
Basically, when a PHP script is called, two things happen :
the script is "compiled" into opcodes
the opcodes are executed
APC keeps the opcodes in RAM ; so the file doesn't have to be re-compiled each time it is called -- and that's a great thing for both CPU-load and performances.
To answer the question a bit more :
4,000 lines is not that much, speaking of performances ; Open a couple of files of any big application / Framework, and you'll rapidly get to a couple thousand of lines
a really important thing to take into account is maintenability : what will be easier to work with for you and your team ?
loading many small files might imply many system calls, which are slow ; but those would probably be cached by the OS... So probably not that relevant
If you are doing even 1 database query, this one (including network round-trip between PHP server and DB server) will probably take more time than the parsing of a couple thousand lines ;-)
I think it would be better if you could split the functions file up into components that is appropriate for each page; and call for those components in the appropriate pages. Just my 2 cents!
p/s: I'm a PHP amateur and I'm trying my hands on making a PHP site; I'm not using any functions. So can you enlighten me on what functions would you need for a site?
In my experience having a large include file which gets included everywhere can actually kill performance. I worked on a browser game where we had all game rules as dynamically generated PHP (among others) and the file weighed in at around 500 KiB. It definitely affected performance and we considered generating a PHP extension instead.
However, as usual, I'd say you should do what you're doing now until it is a performance problem and then optimize as needed.
If you load a 4000 line file and use maybe 1 function that is 10 lines, then yes I would say it is inefficient. Even if you used lots of functions of a combined 1000 lines, it is still inefficient.
My suggestion would be to group related functions together and store them in separate files. That way if a page only deals with, for example, database functions you can load just your database functions file/library.
Anothe reason for splitting the functions up is maintainability. If you need to change a function you need to find it in your monalithic include file. You may also have functions that are very, very similar but don't even realise it. Sorting functions by what they do allows you to compare them and get rid of things you don't need or merge two functions into one more general purpose function.
Most of the time Disc IO is what will kill your server so I think the lesser files you fetch from disc the better. Furthermore if it is possible to install APC then the file will be stored compiled into memory which is a big win.
Generally it is better, file management wise, to break stuff down into smaller files because you only need to load the files that you actually use. But, at 4,000 lines, it probably won't make too much of a difference.
I'd suggest a solution similar to this
function inc_lib($name)
{
include("/path/to/lib".$name.".lib.php");
}
function inc_class($name)
{
include("/path/to/lib".$name.".class.php");
}