views:

184

answers:

7

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?

+1  A: 

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");
}
Chacha102
good idea thanks
jasondavis
+1  A: 

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?

Fabian
the php.net site has all the native php functions, however you can create code that does certain functions/task and put it into your own funtion, which can be called over and over again, so you don't have to e-write that same block of code a hundred times
jasondavis
+1  A: 

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.

Joey
+4  A: 

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).

zombat
Remember though, that those 4k lines ahve to be parsed and run for _every_ page access. Unless you have some optimizer running which caches compiled bytecode, but last I looked those things come at a cost and so aren't usually installed unless you paid for it.
Joey
Yes, that is true. But there is also a cost for disk seeks for dealing with multiple files. If you assume he splits it into 10 files of 400 lines each, and on average he includes 4 of them in each file, then he's down to 1600 lines of code and 4 files. The question is whether the reduction in number of lines parsed outweighs the added include() overhead. I postulate that the difference will be extraodinarily minor. The only way to be sure of course is to benchmark it. Truly though, if you're at that level of optimization, an opcode cache would be time much better spent.
zombat
ok thanks for the comments, If I ever do decide to break into smaller files, like forums functions, blog functions, and so on, since my site has hundreds of pages that all include my 1 functions file, I could just put in my code that need to determine which files to load inside of that included function file instead of editing a bunch of files right? I know it wouldn't be a pretty but would be ok?
jasondavis
also I plan on using APC and memcache soon, im just trying to clean up my code some, increase some performance here and there, and a little restructuring while my site is offline for a couple weeks. I also have a seperate server for mysql maybe I should put memcache on there also
jasondavis
+3  A: 

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 ;-)
Pascal MARTIN
+1  A: 

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.

Peter Spain
good points thanks
jasondavis
+1  A: 

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.

Alfred