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
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Post by Buddha443556 »

Roja wrote:I'll happily take a one-millionth of a second increase to be able to comfortably use OOP where it feels appropriate. Arguing otherwise makes me think of the optimization in programming rule: Premature optimization is the root of all evil. :)
The saying, "premature optimization is the root of all evil" has it's origin in compiled languages, such as C, were the structure of your source code files has no effected on the performance of the resulting executable. The optimization performed by a compiler, for a language such as C, is done not only at the source code level abut at the native code level which encompasses complete source of the executable. PHP [and Zend Optimizer] only operates on one source file at a time at the byte code level. There's a big difference between the optimization PHP performs and that of a compiled language such as C.

Otherwise I agree the speed of PHP is not an issue.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Buddha443556 wrote:There's a big difference between the optimization PHP performs and that of a compiled language such as C.
Agreed, but its still an issue even in PHP.
Buddha443556 wrote:Otherwise I agree the speed of PHP is not an issue.
Oh I didn't say that, and don't agree. I think speed *is* an issue. However, I think avoiding OOP because of the potential loss of a millionth of a second for using classes is definitely premature optimization.

There are endless other opportunities and areas for improvement that would yield greater improvements, and if speed *isnt* an issue for a particular app or website, then its really not neccessary to optimize at all.

I think PJ is right that if you want to squeeze every last drop of performance out, that there is a measurable hit to using OOP. My counter argument is that the measurable gain is insignificant for the overwhelming majority of apps. I'd be deeply surprised to see an application that actually improved by a single second on a single pageload by avoiding OOP entirely.

There are apps, and places where optimization are needed, but they are the exception, not the rule.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

What I'd be interested in is whether using references instead of newly instantiated class in each iteration of the example code makes a performance difference.

P.S.: moved to Theory & Design
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

PHP automatically creates objects by reference when the new operator is used.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

Jenk wrote:PHP automatically creates objects by reference when the new operator is used.
Yes, but only since PHP5. The article that started this discussion was written in 2003, i.e. PHP4 time, when you had to use $bla =& new myclass(); for a reference.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

I was hinting that you already have your results, since some of the board members have produced their results on PHP5..
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

Jenk wrote:I was hinting that you already have your results, since some of the board members have produced their results on PHP5..
The object oriented model for PHP5 was a complete rewrite from PHP4 and is fundamentally different. Hence saying: if it's passed by reference in PHP5 will give the same results a PHP4 is untested. Given that PHP4 is still running on the majority of webservers (and PHP being the most used server-side scripting language) it's quite relevant to find out what the performance of that code using references under PHP4 would be.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

This is a converstation that happens over and over. I believe that the arguement for OO is usually that organizing you code using OO gets you some benefits if you know how to use it (I hope we don't need to go through them). Conversely if you use OO constructs to write procedural code -- that is worse than just using functions -- a point frequently proven in PHP.

One question I would have about the benchmarks in question is: what version of PHP was being used. I didn't see it listed. The copyright was 2003 and the processor was a 2Ghz Xeon which is a few generations back. I would be interested to see how the latest release of PHP5 performs -- though I assume that the OO constructs will always be slower.
AKA Panama Jack wrote:If you want pure speed you do not use OOP. For those that say OOP is more structured they have just been brainwashed. :) Procedural can be just as structured as OOP without losing the advantage of speed.
I don't think people say that OOP is "more structured" nor do I think that the huge number of OO programmers (and the majority of other languages) have been "brainwashed." OO prvides many benefits for application development. Speed is one of many cocerns in application development. The idea that a complex application will be faster if written using procedural techniques rather than OOP has never really stood up. In fact, the reason most large application development is done using OO is that creates a code environment that makes refactoring to improve the program (performance or otherwise) easier.

The "pure speed" idea is a little odd anyway as the benchmarks show. Looping a million times? Performance is really about algorithm choice and optmizing sub-systems.

My point is not to convince you that either procedural or OO are better -- both are currently needed to code PHP.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

Do not make this a OOP vs Procedural debate. If you are interested in more information about OOP vs Procedural there are plenty of good threads already, just search for them.
User avatar
patrikG
DevNet Master
Posts: 4235
Joined: Thu Aug 15, 2002 5:53 am
Location: Sussex, UK

Post by patrikG »

it's not about OOP vs. procedural. It's about the performance differences in OOP implementations of different PHP versions to my mind. Much more granular than just "procedural: hurray!" vs. "OOP: hurray!".
User avatar
hawleyjr
BeerMod
Posts: 2170
Joined: Tue Jan 13, 2004 4:58 pm
Location: Jax FL & Spokane WA USA

Post by hawleyjr »

Side note: Does anyone care if I change this topic from "Badly Written Code" to "Poorly Written Code"?

Sorry, It's been driving me nuts...
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

patrikG wrote:it's not about OOP vs. procedural. It's about the performance differences in OOP implementations of different PHP versions to my mind. Much more granular than just "procedural: hurray!" vs. "OOP: hurray!".
I agree. Knowing in general what you are dealing with with different constructs and libraries can be useful (is it 2:1, 10:1, 100:1?).

There is a grey area between Premature Optimization and simply making reasonable design decisions based on knowledge.
User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Post by AKA Panama Jack »

arborint wrote:One question I would have about the benchmarks in question is: what version of PHP was being used. I didn't see it listed.
On my system (3.2 gig P4 under XP Pro running XAMPP Server)...

The initial test was performed on PHP 4.4.1.

Code: Select all

$cnt+=$testclass->one();
1000000 times for 2.9005510807 seconds

Function Procedural
1000000 times for 1.00571393967 seconds

Straight Procedural
1000000 times for 0.375358819962 seconds

$cnt+=test::one();
1000000 times for 1.5131418705 seconds

OOP with class instance outside loop
1000000 times for 1.4020409584 seconds
On my system (3.2 gig P4 under XP Pro running XAMPP Server)...

The same test on the same system using PHP 5.1.1

Code: Select all

$cnt+=$testclass->one();
1000000 times for 1.87981390953 seconds

Function Procedural
1000000 times for 0.762351989746 seconds

Straight Procedural
1000000 times for 0.178838014603 seconds

$cnt+=test::one();
1000000 times for 2.78865814209 seconds

OOP with class instance outside loop
1000000 times for 0.989754199982 seconds
What I find interesting that using test::one() on PHP 5.1.1 is incredably slow and the slowest method of all. There is improvement on creating a new object inside the loop.

Plus PHP 5.1.1 does seem to improve the execution speed of procedural functions and straight procedurals.

It still comes down to OOP under current and older versions of PHP are slower. Also, using a precompiler like eAccelerator doesn't help all that much. You still have the same RATIO differences in speed of execution.

arborint wrote:The idea that a complex application will be faster if written using procedural techniques rather than OOP has never really stood up.
Actually you are right as long as you are not talking about OOP usage in PHP. Using OOP programming in compiled languages like C you will not notice any difference because you do not have the same instance allocation overheads that PHP includes. Because PHP is basically an interpreted language OOP will always be slower in execution. Even after PHP has been byte-encoded using a precompiler/optimizer you will still have the same overhead problems. Maybe PHP 6 will address these issues but I have serious doubts about it at this time.
User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Post by AKA Panama Jack »

Here is another test that shows how the size of the object influences the speed of execution.

The following results are the exact same setup but there is 63k of code added to the test object. This 63k of code comes from the ADODB ADOConnection object.

On my system (3.2 gig P4 under XP Pro running XAMPP Server)...

The initial test was performed on PHP 4.4.1.

Code: Select all

$cnt+=$testclass->one();
1000000 times for 35.4844899178 seconds

Function Procedural
1000000 times for 0.982064008713 seconds

Straight Procedural
1000000 times for 0.466929912567 seconds

$cnt+=test::one();
1000000 times for 1.26907491684 seconds

OOP with class instance outside loop
1000000 times for 1.37708210945 seconds
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.

You can imagine what the results would be on a server with a 1 gig single core processor. :) The 3.2 gig processor the above tests were performed on is a dual core.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

35 seconds!
Post Reply