PHP Parsing Speed

Anon

I have a huge library file with every function my site as a whole needs. This single file does every operation in my site, and is included by every page. However, I was wondering if by having this huge file parsed every time, I was having a big slowdown in my site\'s operation. Would it be faster, if less convenient, to have individual library files that are included separately by the respective pages that actually need the functions?

[deleted]

You'll have to benchmark which is faster:
one big include() or several smaller ones.

Remember, opening a file and parsing it is an expensive operation, so you'll have to be very carefull if you are really bent on getting the most out of php.

The main thing is to benchmark and not speculate on what 'might' be faster.

Anon

It's not really one big file vs several smaller files. It's really a matter of whether PHP takes time to parse functions.

[deleted]

Uhm... ok?
Ofcourse it takes time for PHP to parse functions. That's a given.

If you have one big file now, it means that each script parses a lot of functions that it doesn't really need. agreed? agreed, because that was in your original post.

Now, if you make smaller files that contain only the functions that each script needs, you end up making copies of the functions because some functions may be required in several scripts. And that's not what you want (unless you are a workaholic)

Thus you end up with many smaller files, some with functions that are special for one script, some with functions that are used in several scripts.

Then it's down to benchmarking to see which is faster,
but more importantly, can you maintain your scripts if there are 46 of them, all with different relations to eachother?

kparker

Well, I think there's a middle ground: cut the big php include-file into a few smaller files based on functionality. This is similar to what the C standard library does--you can say:

   #include <stdio.h>
   #include <stdlib.h>

rather than

   #include <fopen.h>
   #include <fclose.h>
   #include <fgets.h>
   #include <printf.h>
   #include <fprintf.h>
   #include <malloc.h>
   #include <atoi.h>
...
No need for duplication of functions, and you can still get a decent reduction in parsing time for programs that don't include all the modules.

I completely agree with Vincent about the need to measure stuff rather than just conjecturing. I would even say you should measure the current speed of the parsing before you decide to embark on this journey at all. You could well find that, even if you're unhappy with the site's speed, that the Grand Unified Include File only accounts for 5% of that total. If so, would it be worth spending even 2 minutes to speed up your site by 5%? I sure wouldn't bother...

Anon

Ofcourse it takes time for PHP to parse functions.

But does it really? If you have an error in a function, PHP won't report the error unless you actually make the call... so is it really parsing the functions?

[deleted]

--quote--
Well, I think there's a middle ground: cut the big php include-file into a few smaller files based on functionality. This is similar to what the C standard library does--you can say
--quote--

That is what I meant.
scenario a) one include file for each script, and each include file has all the functions required for that script (lots of replication)

scenario b) include files organized by functionality. NO duplication, but each script must include several files.

A is not what you want,
and for B you really should benchmark and think about which functions go where, because if you have 40 include files, you'll sacrifice quite a bit of time just loading the files.