Richard Lynch wrote:
On Mon, May 1, 2006 8:25 am, Edward Vermillion wrote:
What I was mainly thinking of though, what kind of hoops does PHP
jump through to take a class, that I assume it's holding in memory,
and make an object out of it, aside from the constructor? Is it
doubling the memory consumption, or more, to do that by having the
class and an object ready to work on? Are objects stored differently
from included classes? Or is it treating it like object references(?)
and only making a copy when it's necessary? Or something else
entirely?
I don't know exactly how PHP handles a static function -- whether it
has a ghost instance laying around, or cached as needed, or maybe they
just fake it with a bogus object and call settype() on it a lot.
niether from what I gather - calling a class method statically (as opposed
to calling the method on inistantiated object) is tantamount to calling a
regular function - although I would imagine that there is some overhead in
the engine as it tries to setup a reference to the non-existant object
I don't think you need to worry about having a single "extra" instance
of every class.
have a _big_ stack of classes probably (generally speaking - which is badform in IT
I know) incurs more overhead at the compilation stage than creating 1 instance
of each in your scripts.
You generally only get into trouble when you start building factories
churning out a zillion instances of some classes.
in php5 a good dose of cloning and if your really crazy (hi world :-) some
shared memory serialized object caching goes a long, long way :-) - not to
mention using APC or something akin to cache the opcodes of your code, which
can do wonders for the speed of your scripts.
I think you'd have to REALLY work at it and screw up Design big-time
to get enough classes that the overhead of just the class itself would
take all your RAM.
and you would spend a long time writing the code :-)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
