Poorly written code?

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Has such a topic ever led to a valid compromise? ;) Since the advent of PHP there has been a surge in OOP designs taking full advantage of interfaces, abstracts, and design patterns. They are of course going to hit some performance issues. For many people its probably not a huge issue, then again when you're stuck on a shared server with limited resources it can make a surprising difference.

I don't think there is a compromise - not until someone manages to make PHP itself more efficient. So the arguments for each side will continue.

Even I still remember the shock of seeing a simple sounding PHP utility pulling in no less than 46 classes if you counted interfaces, abstracts, etc. I think that sort of example illustrates that the performance argument does have a lot of merit. There are some awesome OOP designs out there in need of some level of efficiency improvement.

46 classes??? I use less on a full blown application.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

I have to say, PHP 5.1 is often leaps faster than any previous version. :)
User avatar
tasteslikepurple
Forum Commoner
Posts: 46
Joined: Thu Jan 26, 2006 3:38 am
Location: Bath, UK

Post by tasteslikepurple »

Buddha443556 wrote: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.
it's not just a PHP problem, this problem is true with all OOP applications. It's because functional approaches are easier for the machines to 'understand' (performance), whereas OOP is easier for humans to read and understand (maintainability).

P.S. I like the way that the thread has changed from poorly written code to a OOP vs functional programming debate!
User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Post by AKA Panama Jack »

arborint wrote:
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.
Actually I am very familier with OOP programming. I have been doing it for many years on different languages. :)
arborint wrote:
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.
Actually the server resources aren't scarce. Bandwidth limitations come into play way before server resources even get close to being a limitation. ;)
arborint wrote:
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.
Actually they care ALOT. You will find most hosting companies with virtual hosting have server usage limitations based upon one of many or all factors from bandwidth usage to CPU usage to database queries/usage. Most hosting companies have a limit of 10% CPU load per site for a set number of seconds. If you go over those limitations they usually require you to change to a dedicated server. It is very EASY to go over those limits if you have a moderately active site that uses alot of OOP coding.
arborint wrote:
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.
Yes, but that is because you can tell the client they need to upgrade thier servers instead of making the code better. That is alot of the problem with programming anymore. Programmers hope everyone will throw hardware at the problem instead of making the programmers create more efficient code. :)

If you look at what I have posted I have nothing against OOP programming. OOP programming is great depending upon the language using it. Creating an application that is totally OOP driven in C doesn't have any of the limitations of a totally OOP application written in PHP. PHP has some serious issues with memory allocation and creation of OOP objects. Especially if they are large objects. From the way PHP seems to act, and I haven't gone into the internals, it is almost like it is performing a line by line EVAL on the object being created. That's about the only reason I can think for it being so SLOW in creating a new object because allocating the needed memory would not be that slow.

If they were to greatly reduce or eliminate the high overhead in creating an OOP object in PHP then I would agree everyone should use OOP as often as they can... Maybe they will make progress with PHP 6 but PHP 4/5 still have some serious overhead issues.
Last edited by AKA Panama Jack on Fri Jan 27, 2006 4:36 pm, edited 3 times in total.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

tasteslikepurple wrote:it's not just a PHP problem, this problem is true with all OOP applications. It's because functional approaches are easier for the machines to 'understand' (performance), whereas OOP is easier for humans to read and understand (maintainability).
I'm not sure that "functional approaches are easier for the machines to 'understand." It is really the additional level of abstraction that adds additional code. In PHP OO there are additional constructs. When you compare them directly to functions (which is apples and oranges) there is a performance difference, but it does not take into account the fuctionality difference. For the overall application OO can provide some code reduction which might offset the code of the addtional constructs. That's why simple comparisons are misleading.
tasteslikepurple wrote:P.S. I like the way that the thread has changed from poorly written code to a OOP vs functional programming debate!
I actually wasn't about "poorly written code" per se. If you look at the page linked to by the first post -- it was about misleading benchmark code -- not application code.
(#10850)
User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Post by AKA Panama Jack »

Buddha443556 wrote: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.
Well you can still have maintainability without sacrificing performace. :)

The problem is you can sacrifice performace using PHP if you adhear to an OOP is the only way to have maintanability attitude. Once they fix the performance problems with creating an OOP object under PHP then this type of discussion will become moot.
Last edited by AKA Panama Jack on Fri Jan 27, 2006 4:37 pm, edited 1 time in total.
User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Post by AKA Panama Jack »

Maugrim_The_Reaper wrote:I don't think there is a compromise - not until someone manages to make PHP itself more efficient. So the arguments for each side will continue.
How true. :) I would probably use more OOP in PHP if the instance overhead for objects was greatly reduced or eliminated.
User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Post by AKA Panama Jack »

tasteslikepurple wrote:it's not just a PHP problem, this problem is true with all OOP applications. It's because functional approaches are easier for the machines to 'understand' (performance), whereas OOP is easier for humans to read and understand (maintainability).
Actually it's not a problem with other languages. PHP is kind of unique in this regard. OOP is kind of something they initially tacked onto PHP. One would hope they would make OOP the basic groundwork for PHP 6 if they want to remove the OOP overhead in PHP.
Post Reply