From: David Harkness on
On Thu, Jul 22, 2010 at 2:40 AM, Ashley Sheridan
<ash(a)ashleysheridan.co.uk>wrote:

> The larger a script or class is, the more memory this uses per instance.
>

This is not quite true. When the 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--not the number or length of its methods. PHP creates a single
internal Class object to contain the methods, and this indeed takes memory
proportional to the number of methods, but this doesn't affect the
instances. Each instance stores only its instance properties such as
$this->firstName.

This correction aside, the advice here is spot on: split your classes based
on responsibilities. The reason for this has more 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.

Peace,
David
From: Nathan Rixham on
Sebastian Ewert wrote:
> Hi,
>
> I'm developing an joomla component and my helper an user classes are
> crowing bigger and bigger. The helper class is for static use only.
>
> Does class size decrease performance of my php scripts, even for static
> usage?
> Is there a general rule when to split a class to keep performance up?

If you think about it, each class, function, method, line of code all
gets interpreted in to opcodes and executed - so, no matter how you
split it up, it's still going to produce roughly equivalent opcodes.

Thus, no.
From: David Harkness on
On Sat, Jul 24, 2010 at 5:57 AM, Nathan Rixham <nrixham(a)gmail.com> wrote:

> If you think about it, each class, function, method, line of code all gets
> interpreted in to opcodes and executed - so, no matter how you split it up,
> it's still going to produce roughly equivalent opcodes.
>

An exception to this is when you have a class that can be heavily
refactored. For example, say you have a data access class that operates on
books in the database (standard CRUD) and also generates XML and JSON views
of the books. If you refactor the class to extract the XML and JSON export
into separate classes--something that should be done for many other
reasons--you won't have to load and parse that code when you're not
exporting the data.

David