Re: OOP Static Functions vs. Objects

On 5/1/06, Edward Vermillion <evermillion@doggydoo.net> 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 classes? Or is it treating it like object references(?) and only making a copy when it's necessary? Or something else entirely?

From what I've read, php5 uses references with objects (hence why you need "clone" for example). php4 doesn't.

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.

Only include the classes as you need them and you should be fine. If you're still worried, do some checking with memory_get_usage and do some timing tests. -- Postgresql & php tutorials http://www.designmagick.com/