"performance impact" when using a 20K lines single class

Question

This question was asked here before, but none of the answers really tried to answer the actual question asked, so I'm asking it in a different way. Is loading a single class of 20,000 lines with 100s of functions more resource intensive in any way than breaking up the code to smaller classes with fewer functions each and loading these smaller classes as needed?

Hungnam

Obviously, this depends on the use case. If you break them up, and end up using only say 1% of it and load only this 1% of it, of course it will be less resource-intensive than loading 100% and then using 1%. – Waterfall

You are asking two different things here. The "performance impact" is zilch. While "resource intensive", yes it is, memory-wise. If you break your code up into smaller parts, then you'll have less memory usage, but eventually more I/O. Use xdebug instead of generalized advise. – Pine

Performance should not be your concern here... the benefits you will reap in maintainability and being able to read the code will vastly outweigh any (probably minor) performance impact that could occur. – Hyacinthie

Answer 1

The larger a script or class is, the more memory this uses per instance. Out of the box, PHP doesn't have a way to share the memory space of libraries and classes, so creating massive scripts for a website is not a great idea.

The typical approach should be to break classes down into blocks such that you need only include per script what you actually need to run that script.

Also, it's unlikely to cause you performance problems unless you've got a huge amount of traffic - and then you could probably fix your problems easier than refactoring classes.

When a script is loaded, it requires a fixed amount of memory to parse it. The larger it is, the more memory it requires. Next, the script itself is executed, running any top-level code (not in a class or global function). If that includes any require/include statements, those scripts are loaded (if necessary). If it creates objects, that takes more memory.

However, the size of each instance of the class is affected only by the data it stores. This correction aside, the advice here is spot on: split your classes based on responsibilities. The reason for this has also to do with ease of development than performance. Say you have one monster class filled with static methods. If your application uses most of those methods for each request, splitting it will have no performance benefit because both scripts will end up being loaded anyway. But if you can group the methods into logical subsystems, they will be easier to understand and work with.

Calandracalandria

Agreed. One mechanism that can make this easy (after you've broken your library down into single classes and files) is PHP 5's autoloading. – Albie

@Pekka, please don't mention the A word. I officially hate it, because I don't quite understand how to add it. – Hungnam

@jblue, are you talking about 'autoloading' ? There are some nice tutorials for that, if you're having any problems. – Calandracalandria

@Hungnam :) But it is really great. To me, it's the greatest thing since sliced bread because you don't have to include() stuff anymore and you're guaranteed not to embed unused code. Maybe this helps? #2303412 otherwise, maybe ask a separate question on the issue? – Albie

Answer 2

One big class require single cycle to compile into binary code (op-code).

Many smaller classes using lesser memory but require more compilation, and the memory use for compilation will be accumulated.

Is really depend how many classes/files has been included in run-time.

So, solution for this, break into multiple classes and use APC or equivalent.

PS: the memory consumption for the big file is much smaller, because PHP do not need to re-compile the source into op-code (if you reluctant to break the big class into smaller)

Housebreaking