AKA Panama Jack wrote:BDKR wrote:
It "can be" and "has been" proven (try to find some of John Lims test of Adodb) that OO code will execute slower then PHP. But that's not algorithmic issue (like the one Harry was bringing to light).
As you can see from my signature I am the author of a program called ADOdb Lite. It is a package that is designed to have most, if not eventually, all of the functionality of ADOdb but use less memory and execute much faster.
If you use the tests most people use that test how fast the query executions for select, insert and update on ADOdb, Mysql functions in PHP and ADOdb lite you will notice that there isn't that much of a difference in execution speed. Now when you factor in the creation of the objects on a page load bases then you see where the slowdown comes. I modified the benchmark suite that John provided for testing ADOdb's speed so there is a test for ADOdb Lite. You can download it here
http://prdownloads.sourceforge.net/adod ... p?download .
Using Microsofts Web Stress Test program you can see how many pages per second any web page can generate. You can see the benchmark test results here
Benchmark. The test was performed on my home lan so there was zero latency involved. You can see a huge difference in pages per second and this is all because of the size and methods used by each class to create the object. One of the items that seems to really slow down creating a new object is when you extend a class and the extension has functions that replace functions of the same name in the main class.
It's not so much the execution speed of the classes that is the problem but the creation of the objects from a class that can cause a impact upon server performance. And the bad thing is PHP 5.0.x is even slower in this respect. Hopefully in the later versions they will be able to get a handle on this and speed things up.
I didn't know it was you that did Adodb lite. Nice work. You certainly dealt well with the main gripe against Adodb wich was the size of it's library. The overhead of parsing it alone is pretty sizeable. It's obvious in the speed up when used with an accellerator.

How much of the difference in performance between Adodb and Adodb Lite is due to this? It's obvious from your own tests that it's immense as the percentage (of how much faster your lib is) dropped from 300% to 30%.
Of course, depending on the application being developed, the additional functionality that makes up the rather large size of Adodb is justified. In an in house ERP application for example, I feel this would be justified.
Anyway, in looking more at your benchmark, it's not telling me anything that would support your claims. One of the things it states is that ...
from the benchmark wrote:
Below are the pages per second generated using the Microsoft Web Application Stress Tool...
{ The above emphasis is mine }
"
pages per second indicates to me that the instantion process was suffered for each page view. OK store that in memory for a second. The number of pages generated with the straight mysql commands was 101.6 as opposed to 88.34 for Adodb Lite. Keeping the last couple of sentences in mind, the question then becomes "how much of that difference is attributed to the overhead of instantiation alone"? Based on your statements so far, it would
seem (if I'm understanding you correctly) that the bulk (or even all?) of the difference is indeed attributable to instantiation alone.
Now I may be wrong here but it's hard to believe that instantiation accounts for that much overhead alone. But that aside, John did some tests that indicate some differences elsewhere.
Optimizing Object-oriented Programming
In March 2001, I conducted some informal benchmarks with classes on PHP 4.0.4pl1, and I derived some advice from the results. The three main points are:
1. Initialise all variables before use.
2. Dereference all global/property variables that are frequently used in a method and put the values in local variables if you plan to access the value more than twice.
3. Try placing frequently used methods in the derived classes.
Warning: as PHP is going through a continuous improvement process, things might change in the future.
More Details
I have found that calling object methods (functions defined in a class) are about twice as slow as a normal function calls. To me that's quite acceptable and comparable to other OOP languages.
Inside a method (the following ratios are approximate only):
1. Incrementing a local variable in a method is the fastest. Nearly the same as calling a local variable in a function.
2. Incrementing a global variable is 2 times slow than a local var.
3. Incrementing a object property (eg. $this->prop++) is 3 times slower than a local variable.
4. Incrementing an undefined local variable is 9-10 times slower than a pre-initialized one.
5. Just declaring a global variable without using it in a function also slows things down (by about the same amount as incrementing a local var). PHP probably does a check to see if the global exists.
6. Method invocation appears to be independent of the number of methods defined in the class because I added 10 more methods to the test class (before and after the test method) with no change in performance.
7. Methods in derived classes run faster than ones defined in the base class.
8. A function call with one parameter and an empty function body takes about the same time as doing 7-8 $localvar++ operations. A similar method call is of course about 15 $localvar++ operations.
Update: 11 July 2004: The above test was on PHP 4.0.4, about 3 years ago. I tested this again in PHP4.3.3 and calling a function now takes about 20 $localvar++ operations, and calling a method takes about 30 $localvar++ operations. This could be because $localvar++ runs faster now, or functions are slower.
I emphasised some points in there that are more pertinent to our conversation as the text above is focused on optimizing code.
Notice also that he found the same thing about the execution time of methods in derived classes as you.
Anyway, if you look at his
comparisons between Adodb and some other prominent DB layers, you note that he also compares all of them to straight MySQL functions as you do. All of them are slower then just using procedural code.
Average Overhead
MySQL 1.14 -
ADOdbext 1.30 14%
dbx 1.37 20% (index only)
ADOdb 1.45 27%
dbx 1.53 34% (index/assoc/info)
PhpLib 1.60 40%
MDB 1.75 54%
PEAR DB 2.87 152% (fetchInto)
PEAR DB 3.15 176% (fetchRow)
M'base 2.52 296% (numeric cols)
M'base 4.77 318% (assoc cols)
Of course, the poor performance of some of these is not all due to the mere use of OO. There are some algorithmic issue among other things that are contributing to this. Perhaps there is some [url=
http://www.joelonsoftware.com/articles/ ... 00018.html]Architect Astronaut[/a] action jumping off? But whatever the case, that certainly blows Harry's orginal thrust (fromt he threads pointed to by sweatje) that OO must led to faster code (by implication of course as the stated idea was that procedural led to slower code).
Anyway, I went ahead and mentioned the above for the simple reason that most people don't and won't pay
ANY attention or thought to how effecient their chosen abstraction layer or framework is. They just use it and that's the end of that. However, as can be seen from the the comparo by John quoted above, not all of them are created equal. The M'base performance as an example, is simply attrocious and for
some applications it's simply unaccetaple.
But back to considering only Adodb Lite vs well written procedural code, what percentage of Adodb Lite's slower performance is attributable to instantiation alone? Once you figure that, then you have a truer number of the differences in performance. [/quote][/u]
One way or the other, you did a great job on Adodb Lite.
Cheers,
BDKR