When is a .php file too large?

Question

I'm writing a PHP class. At the moment there are 1,000 lines of code and the file size is 46 KB. It's not an insane size, but this got me to thinking.

Q: At what point would performance start to be affected due to file size and/or the amount of code included in the PHP file?

Quantity is not nearly as important as Quality. If you have a copy/paste of the same code block anywhere, you are doing it wrong. Create a function. Use switch statements. Nested Ifs. I'd worry more about creating quality code than the quantity. — JClaspill, May 30 '13 at 02:01

score 5 · Answer 1 · answered May 30 '13 at 02:00

5

For php there is no noticeable difference (especially if you use any opcode cache) if there is 10 files each 100 lines or 1 with 1000 lines.

But from maintainability point of view it would be better to split the class responsibilities to several.

answered May 30 '13 at 02:00

zerkms

249,484
69
436
539

-1, there **IS** a noticeable difference per file due to PHP using the lexical parser to convert your code into opcode. – Sébastien Renauld May 30 '13 at 02:21
3

@Sébastien Renauld: could you prove your words and show that parsing of 10 files each 100 lines takes longer (?) than a single file with 1000 lines? Keep in mind that it was your idea to point to a parsing step specifically, so if you will try to prove it (I highly doubt you will do that) - then only measure parsing step (and exclude everything else, ie runtime). – zerkms May 30 '13 at 02:27
http://pastebin.com/6juAXCGb , initialize with any old class constant, it will create 1000 files. run-time for the 1000 files is around 0.150 microseconds, runtime for the one include is around 0.080 microseconds. This was run with APC disabled (**and this is important**) – Sébastien Renauld May 30 '13 at 03:01
1

@Sébastien Renauld: 1. it is 1 file vs 10 files (not vs 1000). 2. You said there is a significant difference **due to parser**, while if you just run the files the overall time is sum of: IO, parsing, runtime. If you want to be a 100% precise guy (and I hope you want to be - otherwise you wouldn't comment) - then follow **your** words and provide tests that prove any significant difference for **parsing** (of exactly the same amount of code being placed in one file and splitted to 10 files). Do you realize the difference between parsing and running? I hope you do. – zerkms May 30 '13 at 03:34

score 3 · Answer 2 · edited May 23 '17 at 11:57

Like other people have suggested, the main focus on file size should be towards readability and keeping the codebase understandable.

However, regarding your original question regarding PHP file size and performance, it depends on what type of performance is needed. For PHP code that is executed infrequently--such as a PHP program executed on the client's machine via the command line, rather than by visitors loading a webpage--large file sizes may not be noticable.

In contrast, in high-performance scenarios, even fairly small PHP file will consume substantial system resources. The general issue of PHP performance is what drove Facebook to write their own JIT virtual machine for executing PHP code--because once-acceptable performance with PHP became horrifying as Facebook scaled up.

The above is true for optimization in general--it is difficult to draw a line between good and bad performance without having a broader context to classify within. If you are concerned about the performance of your PHP code--whether file size-related or not--I recommend using a PHP profiler like Xdebug and monitoring the system resources on your server.

EDIT, At the suggestion of Sébastien Renauld, I add the following information about PHP and opcode caching to my answer. Rather than writing it all myself, though, I would like to point out the accepted answer on this StackOverflow question that covers nearly the same topic.

This addresses every point much better than any other of the other answers. +1, might be worth mentioning the effect of opcode caches on the "file number and performance", by the way. — Sébastien Renauld, May 30 '13 at 02:20
Your answer skips over the 99.9% of scenarios that fall between "executed on the client's machine via the command line" and "Facebook". — Ja͢ck, May 30 '13 at 02:41
In those cases, and assuming an opcode cache is used, how the code is organized is secondary to what it does. — Ja͢ck, May 30 '13 at 02:47

score 0 · Answer 3 · answered May 30 '13 at 02:26

I am not an expert on anything, but I will say that you probably won't run into problems until your file size is a significant proportion of your PHP Memory Limit.

And I will tell you, I've got a mess of code in one PHP file. I just checked and it is 11,487 lines.

That file, and another at 2,056 lines, are both included on every page of my development site.

I am seeing no apparent performance problems.

Perhaps I should explain why I have such a large file.

I am focused on getting the entire program working. And I decided to just use that one file for most classes so that I could easily search it and make changes in any class without looking for a file. After I'm done, I'll split all the classes into separate files and use autoload to only load the required classes. That probably won't be for a few weeks, but when I do I will do some benchmarking before and after to see if there's any performance difference, but I doubt there will be.

Right now, every page on my site loads that file. I just loaded the home page and according to Chrome it took 102ms. A page that actually use a lot of the classes and do some data intensive work and interacts with MySQL took 279 ms.

So it seems to me that the file size does not get to be important until it is much larger than my 11,487 lines. For speed, you need to worry more about optimizing your code.

For example, I just asked a question about array processing in which some solutions had my code run over 5 minutes, some 30 seconds, and a couple solutions at about 280 ms. Don't worry about file size!

When is a .php file too large?

3 Answers3