Edward Vermillion wrote:
On Apr 30, 2006, at 8:07 PM, Richard Lynch wrote:
Instantiating an object does have some extra overhead that the static
call bypasses.
How much overhead depends on the complexity of the object, I would
predict that it's mainly in its constructor and any parent
constructors.
Well there's a big bowl of duh that I hadn't even thought of. Thanks
for pointing that out!
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
class != object in any shape or form - the class is a blueprint of an object,
a class is 'some compiled code', and object (reference or not) is a variable.
I wouldn't worry too much about the nitty gritty of memory consumption, basically
the overhead of creating an object should be outweighed by the gains in encapsulating
functionality and data - i.e. if you have a class that contains 5000 lines of
constructor code and is capable (from the class users POV) of doing no more than
storing a single integer then that class is _probably_ a bad design.
classes? Or is it treating it like object references(?) and only making
php5 - all objects are references of the originally create object (using 'new'
syntax) unless you clone them specifically with the 'clone' syntax.
pph4 - all objects are copies unless you pass them around using the PITA '&' syntax.
a copy when it's necessary? Or something else entirely?
Of course I'm starting to worry about all this as I'm watching the
number of classes, and right now objects, grow to, what seems to me, an
astronomical number. Thinking in terms of the UML design it all makes
sense, but I'm starting to get concerned about the impact on
performance. But then I look at some of the other frameworks and they
seem to be doing mostly the same thing I am. Eh.
suggestion:
first design your app.
second write your app.
third test your app.
fourth test the performance of your app.
fifth refactor/optimize if performance sucks.
with regard to design:
1. only load classes when they are needed.
2. keep object creation to a practical minimum.
3. don't go creating classes for abstracting things like arrays, numbers, etc
(because it sucks :-) this doesn't include iterators ;-) (which are not relevant
given that your still writing php4 compliant code)
Thanks!
Ed
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
