Thanks guys!
I guess it comes down to "Don't do anything stupid and you should be
fine" :D
I'm just still in the design stage, and since my past practice was
write/figure out what you did wrong why it doesn't work like it
should/rewrite, I'm trying to cover as many bases as I can from the
beginning.
Thanks to all who answered!
Ed
On May 1, 2006, at 9:39 AM, Jochem Maas wrote:
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
