Page 3 of 4
Posted: Mon Jan 16, 2006 3:11 pm
by alvinphp
i havent read everyones replies, but in that article the person creates a new object 1 million times. IMHO, of course it is going to run slow. that is a very biased article and they used what i consider a very biased example as I could do the same thing with classes and run it much faster by just adding +1 to an attribute in the class.
Posted: Mon Jan 16, 2006 3:21 pm
by foobar
alvinphp wrote:i havent read everyones replies, but in that article the person creates a new object 1 million times. IMHO, of course it is going to run slow. that is a very biased article and they used what i consider a very biased example as I could do the same thing with classes and run it much faster by just adding +1 to an attribute in the class.
It's not "biased", it's just a _simulation_ of what it would look like in a proper application. They're using simple template objects for the sake of showing the pattern, not giving you useful code.

Posted: Mon Jan 16, 2006 5:04 pm
by Christopher
AKA Panama Jack wrote:As you can see the less often you create a new object for a LARGE object under PHP the better. The size of an object has alot to do with the load and resources needed. If you have a very active web site with alot of large OOP then it wouldn't be hard to overload the server compared to a site that used small and limited amounts of OOP code.
That is a very useful measurement .. thanks.
Out of curiosity,is the slowdown linear related to the size of the class? By that I mean, would a 2k class take 1 second, and a 20k class take 10 seconds and your 60k class take 30 seconds?
Posted: Tue Jan 24, 2006 7:33 am
by ed209
Interesting debate, and it's an issue I have been battling with since I (recently) discovered classes (I have no formal training in OOP).
I have a few classes I've written, and some that I got from phpclasses.org which are really handy and make developing web sites much quicker. I've also been keeping track of execution times and noticed them increasing as I use more classes (even just including the class file).
The originally posted article has made me question my use of OOP and at what point do you balance page execution time with the development time for that page?
My PHP pages are up to 0.25 seconds execution time - their none OOP equivalent are 0.005 ish. Is that acceptable? At what point do you decide to ease off the OOP ?
Posted: Tue Jan 24, 2006 7:44 am
by Roja
ed209 wrote:My PHP pages are up to 0.25 seconds execution time - their none OOP equivalent are 0.005 ish. Is that acceptable? At what point do you decide to ease off the OOP ?
That depends on what your goals are.
By way of example, lets say that I have a page to generate, and it takes 0.25 seconds to generate it. Its a fairly large page, with over 45k of output.
If I spend the time on getting the output to be gzipped, switch from gif's to pngs, compress the javascript where possible, and use CSS instead of tables for layout, I'll reduce that output to 30k. 15k of output takes a full second, even on an ISDN line. Even on a T1, or a cablemodem, its almost half a second.
That reduction didn't require me to give up a solid design, easy extensibility, or OOP in general. Even better, its now a savings on every page that uses those techniques.
Which is better? I've saved bandwidth, and delays for the user. Is that the goal?
If the goal is to reduce the impact on the server, there are also other approaches I can take. Benchmark, and see where the slowdowns are. 10-to-1 odds, its primarily in database calls. So optimize the database calls. If you control the DB server, increase the cache. Optimize its settings for the type of calls you make. Perhaps switch table types (innodb v. myisam on mysql).
There are dozens, even hundreds of optimizations you can make. But to choose which to do, you have to define your goals. Do you want to reduce the delay for the user? Do you want to reduce the impact on the server? And then you need to benchmark to find out where in your code those things aren't doing what you want, well enough.
Then and only then, should you try to figure out what to change.
Posted: Tue Jan 24, 2006 8:23 am
by ed209
Thanks for the reply.
0.25 seconds for generating a page of 15K. HTML for the page is opimised + uses css, the css loaded is only relevant for that page. Images are kept to a minimum. In terms of the eventual page sent down the pipe I'm happy.
Where I'm inexperienced is OOP, which leaves me questioning what was in the original article about it's use. Is 0.25seconds a problem? Maybe not and I'm worrying about nothing. What would happen if 4 users arrived at my site at the same time - would the 4th be processed after 1 second? What if 40 arrived? 10 seconds?
Yes, you're right - the time is mostly taken for the querys, and this is done via a class too (ezSQL
http://www.jvmultimedia.com/portal/node/6 ) . But each class file I include also adds another 0.01 ish seconds to the execution.
Posted: Tue Jan 24, 2006 10:46 am
by Christopher
ed209 wrote:Where I'm inexperienced is OOP, which leaves me questioning what was in the original article about it's use. Is 0.25seconds a problem? Maybe not and I'm worrying about nothing. What would happen if 4 users arrived at my site at the same time - would the 4th be processed after 1 second? What if 40 arrived? 10 seconds?
One of the selling points of OO is that because of its reusabilty and testablity that equates to less programmer time over the life of the project. Servers are much cheaper than programmer time. But OO requres an investment to implement properly. Of course, the quality of the design and the skill of the programmer are ulitmately the important things. But OO has proven itself (as have Agile methods), especially as the software gets more complex.
The whole point of a system like PHP is that you don't worry so much about the .01 seconds because you can scale out inexpensively. I'm not saying write bad code, but the goal is to design well and build quickly -- premature optimization cuts against that grain.
Posted: Wed Jan 25, 2006 3:28 pm
by AKA Panama Jack
Roja wrote:By way of example, lets say that I have a page to generate, and it takes 0.25 seconds to generate it. Its a fairly large page, with over 45k of output.
If I spend the time on getting the output to be gzipped, switch from gif's to pngs, compress the javascript where possible, and use CSS instead of tables for layout, I'll reduce that output to 30k. 15k of output takes a full second, even on an ISDN line. Even on a T1, or a cablemodem, its almost half a second.
That reduction didn't require me to give up a solid design, easy extensibility, or OOP in general. Even better, its now a savings on every page that uses those techniques.
I think he is talking about execution time. You are talking about the time it takes to display the page by reducing the amount of content being sent to the browser. There is a HUGE difference between the two.
When you start using more and more OOP you will start increasing the execution time of the page. I think in his example of 0.25 seconds for OOP and 0.005 seconds for non-opp generates the same aount of output being sent to the browser. So your reply of compressing the data will not make any real difference. They will both have the same ratio in execution time but with the compression time added them.
Posted: Wed Jan 25, 2006 3:34 pm
by Roja
AKA Panama Jack wrote:I think he is talking about execution time. You are talking about the time it takes to display the page by reducing the amount of content being sent to the browser. There is a HUGE difference between the two.
I thought he was talking about reducing the time to get the finished product to the user. At the end of the day, THAT is the measure that matters - whether you pick that up in the output layer, or the processing layer, is up to the individual needs for that situation.
If the time to transmit and display is reduced, thats still a reduction for the user - which is the overall goal.
My position is that optimizing the output will give a far larger return on investment, with less impact to development.
Posted: Wed Jan 25, 2006 3:37 pm
by AKA Panama Jack
arborint wrote:One of the selling points of OO is that because of its reusabilty and testablity that equates to less programmer time over the life of the project. Servers are much cheaper than programmer time. But OO requres an investment to implement properly. Of course, the quality of the design and the skill of the programmer are ulitmately the important things. But OO has proven itself (as have Agile methods), especially as the software gets more complex.
That is a misnomer about OOP reusability that is propogated by the OOP pundits.
Way before OOP came on the scene programmers were building libraries of functions that had just as much reusability and testability. We had to do this to increase the speed of creating new applications and projects. I personally have a library of specialized functions I use in other projects that are not OOP but are used just like an OOP would be.
It is all about programming technique and how you learned. The old time programmers know all about this.
As I said before OOP is fine for LIMITED use with PHP due to the massive execution overhead caused by PHP's implimentation of OOP. Sure you will get people saying it doesn't matter because we have shared servers and you can always use a more powerful server. Thing is if I were a hosting company I would rather have 100 sites on my server that were not using PHP OOP and maxing the server than the alternative of 10 sites that did use all OOP and maxing the server. The less load your PHP applications cause the better for everyone.
Posted: Wed Jan 25, 2006 3:45 pm
by AKA Panama Jack
Roja wrote:My position is that optimizing the output will give a far larger return on investment, with less impact to development.
Sure that is one of the things to shoot for but if you break the back of the server in the process you will actually be reducing the time it takes to serve the client and end up costing more and reducing your return on the investment.
That has been one of our goals with our game. We have focused on reducing execution time and server load as the primary goal with reducing the content being sent to the client. We have had the content amount reduced for over a year.

We have also reduced execution times by a factor of over 120 and server loads by a factor of 20 by reducing the amount of OOP being used and by highly optimizing what little OOP that is left.
OOP in PHP is great for highly specialized usage but can be detrimental when it becomes all inclusive.
Posted: Wed Jan 25, 2006 5:07 pm
by Christopher
AKA Panama Jack wrote:That is a misnomer about OOP reusability that is propogated by the OOP pundits.
The vast majority of enterprise software is built using OOP. It is long past "pundits" as it is the norm.
AKA Panama Jack wrote:Way before OOP came on the scene programmers were building libraries of functions that had just as much reusability and testability. We had to do this to increase the speed of creating new applications and projects. I personally have a library of specialized functions I use in other projects that are not OOP but are used just like an OOP would be.
Well ... modular programming is a proven methodology. I am sure you use it to good effect. But when you say "but are used just like an OOP would be" it makes me think you really don't understand what OO is.
AKA Panama Jack wrote:It is all about programming technique and how you learned. The old time programmers know all about this.

I am a bit of a "old time" programmer myself and I don't know about this at all. Your thesis is that methodology cannot make a difference -- whereas the fact is that over time, better ways of doing things are revealed. I learned lots of programming techniques over the years and one of the best choices I have made is to stop doing a lot of them.
AKA Panama Jack wrote:As I said before OOP is fine for LIMITED use with PHP due to the massive execution overhead caused by PHP's implimentation of OOP. Sure you will get people saying it doesn't matter because we have shared servers and you can always use a more powerful server.
Your "massive execution overhead" statement simply is not true from my experience. You work on a PHP based game, which from my point of view is a very specialized application. And as you probably are doing it on your own, server resources are proably scarce. So I can understand where your coming from. But it is not the norm.
AKA Panama Jack wrote:Thing is if I were a hosting company I would rather have 100 sites on my server that were not using PHP OOP and maxing the server than the alternative of 10 sites that did use all OOP and maxing the server.
I am positive that hosting companies could care less.
AKA Panama Jack wrote:The less load your PHP applications cause the better for everyone.
Why? Performance is certainly part of the equation, but not usually at the top in my experience. I find that being able to complete project on-time, testablity, maintainablity, changabiity are all more important than performance.
Posted: Wed Jan 25, 2006 5:39 pm
by Maugrim_The_Reaper
Aborint does have a point - there is a large gap between a PHP game and an enterprise application - I'm not slurring game programming either (Its a hobby of mine too). Thing is I'm mid ways through a heavily OOP dependent game and I have nothing but good things to say about using OOP versus procedural - now from my view that's coming off the back of a legacy game (so my views are skewed from the start...there are few well written legacy apps in PHP IMO).
Personally I find it far easier to develop with OOP. I make less mistakes, it facilitates testing, there is a shocking lack of bugs (most being typos or behavioural breaks), its easily maintained, and it usually does speed development - less dependencies to worry about. Now I suppose I could compormise on design for performance (I intend doing so - its a game not an enterprise level app backed by a dedicated server or five), but doing so too far could ruin all those sweet advantages.
I could drop to a modular design under procedural - but to be honest I've seen such apps that lead to very restrictive designs that can go so far as to raise the barrier for new developers to join. I just like throwing OOP around because I can usually pitch an API that lowers that bar substantially. Fine it performs less efficiently (probably even worse under PHP5) - but I'm willing to pay a certain price for the OOP advantages... Less complex entering development is, the easier it sits with me. I'm the one has to maintain whatever beast is created either way...
Still the above is my opinion - opinions on OOP can vary greatly. Its all a balancing act depending on developer needs. Some of us prize reuseability over anything else, some performance, others time to market, etc. If you're comfortable with your methods than be happy

.
Posted: Wed Jan 25, 2006 8:30 pm
by Roja
AKA Panama Jack wrote:Roja wrote:My position is that optimizing the output will give a far larger return on investment, with less impact to development.
Sure that is one of the things to shoot for but if you break the back of the server in the process you will actually be reducing the time it takes to serve the client and end up costing more and reducing your return on the investment.
To which I reply, with roughly 50 active servers, over the last four years, we've not seen substantial issues.
Its not a completely different circumstance, but there are substantial differences. Every site running an app has a different balance of concerns around bandwidth use, server load, security, and more.
To each their own. But if the focus is to help a low-to-medium traffic site improve the response speed for users, I'll recommend gzipping, graphics conversion, css support, and other traffic savers over avoiding OOP everytime.
And of course, a php compiler.
Posted: Thu Jan 26, 2006 12:01 pm
by Buddha443556
These discussion always seem to come down to a compromise between performance and maintainability. Why? Is there a inherert limitation in PHP that is being ignored? [I'm sure there is.] The compromise between performance and maintainability is one we have each had to make in our PHP programming or will sooner or later. Instead of discussing the pros and cons of one methodology over another, why not try to find a solution that eliminates the need for a compromise? It would no doubt be more constructive at the very least.