Re: OOP Static Functions vs. Objects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux