Page 3 of 4

Posted: Mon Nov 14, 2005 8:29 pm
by sweatje
I think a point that is being missed here is that OOP scales to complex problems better. The fact that you can isolate and thoroughly test objects easier makes OOP a more attractive paradigm for larger scale corporate development. The process of OO design more naturally leads to uncovering the latent complexity in the solutions we create. From a personal perspective, I think OOP leads to faster development, and in general development speed outweighs computer performance (time to market and lost opportunity costs will generally outweigh server costs). Even this statement is based on what I believe is a faulty assumption that OOP is inherently more processor intensive that a similar procedural system. Harry Fuecks debated this more eloquently than me Procedural PHP leads to slower apps and OOP and Performance.

Posted: Mon Nov 14, 2005 9:29 pm
by BDKR
sweatje wrote:I think a point that is being missed here is that OOP scales to complex problems better. The fact that you can isolate and thoroughly test objects easier makes OOP a more attractive paradigm for larger scale corporate development. The process of OO design more naturally leads to uncovering the latent complexity in the solutions we create. From a personal perspective, I think OOP leads to faster development, and in general development speed outweighs computer performance (time to market and lost opportunity costs will generally outweigh server costs). Even this statement is based on what I believe is a faulty assumption that OOP is inherently more processor intensive that a similar procedural system. Harry Fuecks debated this more eloquently than me Procedural PHP leads to slower apps and OOP and Performance.
I think this is a great post sweatje. It also re-iterates a point that has been made before in these discussions.

However, while I agree that Harry did a great job with those posts, what was ulitmately uncovered wasn't surrounding the mechanics of line by line execution of object oriented code, but the fact that procedural code may block one from seeing weaknesses in an algorithm. 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).

HOWEVER, that's not a reason for avoiding it the vast majority of the time.

Cheers

P.S. It's really nice to know that I'm not going to get "McGruffed" for the above post.

Posted: Mon Nov 14, 2005 10:02 pm
by AKA Panama Jack
sweatje wrote:From a personal perspective, I think OOP leads to faster development, and in general development speed outweighs computer performance (time to market and lost opportunity costs will generally outweigh server costs). Even this statement is based on what I believe is a faulty assumption that OOP is inherently more processor intensive that a similar procedural system. Harry Fuecks debated this more eloquently than me Procedural PHP leads to slower apps and OOP and Performance.
Now I kind of agree with the assessment that OOP can lead to faster developement but only in the case of a programmer having a library of classes they are working from for building new sites. If the programmer is going to create all new classes then they will have about the same developement time as someone programming without classes. The one thing that OOP does is allow you to compartmentalize your code better and that can lead to tracking down problems faster as each class can have it's own debugging features built in. The same thing can be done without classes but can be more cumbersome depending upon the programmer.

As I said in my earlier post the execution of the functions inside a class isn't the problem. All testing will show that the execution speed of a function inside a class is virtually identical as a similar function outside a class. You would be hard pressed to find a difference.

The speed problem comes from creating the object. This is what slows down the execution of the code for a web page. PHP is not that fast at creating a class object. The larger the class and the more extensions added to the class coupled with the number of classes and number of objects created from those classes the longer it will take for the web page to generate. And if the programmer is really sloppy in how they create and extend their classes things can get really slow.

Posted: Mon Nov 14, 2005 10:21 pm
by AKA Panama Jack
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.

Posted: Mon Nov 14, 2005 10:36 pm
by McGruff
BDKR wrote:P.S. It's really nice to know that I'm not going to get "McGruffed" for the above post.
Technical debate is always good to see. Keep it up.

Posted: Mon Nov 14, 2005 11:40 pm
by Buddha443556
AKA Panama Jack wrote: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.
How have you chosen to solve this problem exactly? Or does it depend on the classes involved? Have been meaning to look into the differences between your project and ADOdb but since your here ... :D

Posted: Tue Nov 15, 2005 1:42 am
by AKA Panama Jack
Buddha443556 wrote:
AKA Panama Jack wrote: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.
How have you chosen to solve this problem exactly? Or does it depend on the classes involved? Have been meaning to look into the differences between your project and ADOdb but since your here ... :D
I decided to go with a completely different model for the class structure.

I don't allow any overlapping functions in the extensions. With ADOdb you have the main program (adodb.inc.php) which contains all of the functions that are availible in a generic format. The selected driver loads in an extension that replaces those generic functions with functions specific to that driver.

With ADOdb Lite the main program is just a small interface for connecting to the database or executing a query. There are no generic functions that need to be overwritten. The drivers contain all of the functions that are needed. Actually, I could move those connect and execute functions from the main program to the drivers. This model means that each driver file has to have every function.

With ADOdb the driver files only contain the functions that will be replacing the generic functions in the adodb.inc.php file. Unfortunately this causes ADOdb to be a memory hog and very slow at creating the database object.

When I sat down to create ADOdb Lite I made a roadmap of what was needed. The top items on the list were high speed and low memory footprint while maintaining compatability with ADOdb. I tried a number of different methods before I settled on the current one for speed and footprint.

Basically when it comes to classes in PHP you should avoid creating extensions to a class with functions that replace existing functions in the parent class.

Posted: Tue Nov 15, 2005 8:34 am
by BDKR
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. :oops: 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

Posted: Tue Nov 15, 2005 10:35 am
by Maugrim_The_Reaper
Basically when it comes to classes in PHP you should avoid creating extensions to a class with functions that replace existing functions in the parent class.
Hmm, what about abstracts under PHP5 then? We can't always sacrifice design for speed without creating problems in other areas. Sometimes the speed penalty is more than outweighed by design considerations... OOP as a practice is the ultimate example - it is slower than matching procedural of course.

However speed is far more likely to be influenced by design, than simple OOP/Procedural parsing differences. The danger with procedural is that growing spaghetti code will result in serious slow downs as "glue" code is added in to combat incompatibilities in the design. A stupidly simple example is a game like Solar Empire (procedural) which crawls against an OOP variant Quantum Star SE - same game in a different package.
With ADOdb the driver files only contain the functions that will be replacing the generic functions in the adodb.inc.php file. Unfortunately this causes ADOdb to be a memory hog and very slow at creating the database object.
ADOdb uses quite a bit more memory than PJ's Lite variant. Makes a difference when you distribute to users who rely on shared hosting. After using it myself for a few months and tracking its progress certainly looks worthwhile in the small projects I usually work on. We can't all afford to have ADOdb hogging the measly RAM we have to share on hosts...;)

Seriously though, the cleaner smaller design seems obvious as the source of the speed boost. It's not half as crowded as ADOdb. Segregation (given my perusal) seems a lot sharper. If that's maintained as features are added (and modularised) its looking increasingly good as an alternative where you're without multiple dedicated hosts with a lot of visitors...
I think a point that is being missed here is that OOP scales to complex problems better. The fact that you can isolate and thoroughly test objects easier makes OOP a more attractive paradigm for larger scale corporate development.
Agreed. OOP is a wonder to work with once you have the right level of experience. Design Patterns are very handy at that stage. I can't knock procedural on more limited projects however - not everyone is on a corporate streak, and not everyone needs a scaleable application expecting future unpredictable change.

Posted: Tue Nov 15, 2005 11:32 am
by BDKR
Well, I think you've pointed out a lot of things that have been said and agreed upon allready. :wink:

The question of which to use (Adodb vs the Adodb Lite) should be a matter of mission. Decide what you need then go from there. You can't just apply a maxim then run with it. That sounds kinda Golden Hammerish if you ask me. In this case a "smaller is better" mantra could lead to more code in the long run as you try to make up for the lack in the library you chose to start with initially if you faile to accurately identify requiements.
Maugrim_the_Reaper wrote: However speed is far more likely to be influenced by design, than simple OOP/Procedural parsing differences.
I do not agree with your contetion that parsing is of little concern. Did you look at the benchmarks on Panama Jack's site? Notice the increase in speed for Adodb when an accelerator was used? The percentage of increase is greater then 3 fold! Parsing makes a huge difference.

Parsing can be a huge and costly operation. There is no way around that fact. Just use an accellerator and be done with it.

The real question comes back to one of mission. Do you need all of that stuff? Are you going to use it? As an example, I just turbocharged one of my cars. I had all the tools I needed to do so. I could've had more tools but I would've suffered a cost in having them for no reason. Not just the initial expense of purchase, but the room they take up? I could've bought a jack hammer, which is a tool, but I wouldn't have used it.

However, if I say, "I need tools for working on my deck, my car, and my roof", it's a good bet that my tool set is going to be a lot bigger. I pay more in the initial purchase and the overhead of housing and maintianing them, but I'll get use out of them which justifies that cost.

So, once the question of mission is out of the way, then you can choose the right tool set and thereby righteously incur whatever issues surrounding parsing overhead and footprint that may insue. At the same time, you will have made a decision to go OO or not (on one level, all of your code should be OO tho you may not use objects proper). In cases concerning application, game, or erp/mrp (as examples) design, OO is the better choice.

Cheers

Posted: Tue Nov 15, 2005 12:44 pm
by Roja
Maugrim_The_Reaper wrote: ADOdb uses quite a bit more memory than PJ's Lite variant. Makes a difference when you distribute to users who rely on shared hosting. After using it myself for a few months and tracking its progress certainly looks worthwhile in the small projects I usually work on. We can't all afford to have ADOdb hogging the measly RAM we have to share on hosts...;)
Since we've veered a tiny bit off-topic, I'll add my two cents here.

At least in the case of BNT, I have to agree that there are places where ADOdb has a pretty hefty footprint. However, there is a reason I continue to use it (and advocate continuing to use it), and its a point PJ hit on: Features.

I actually use virtually every feature in ADOdb. Whether its the xmlschema, or the (wonderful) error tracking, I use and abuse pretty much everything he has thrown in. I use the performance monitoring, and I've even looked at his far superior date handling as something I want to embrace in my code.

Thats really the key difference.. some games or applications don't use those features, or find better ways to do it. Personally, I found it useful to gain experience with an extremely well known db abstraction layer. I've used it in my job, and more. But even ignoring that value, it really is worth the footprint in BNT. We use the vast majority of features, and wouldnt want to go without them.
AKA Panama Jack wrote: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.
I have to admit, if the features I love in adodb made their way to adodb-lite, I'd jump ship. The memory use in lite is far lower, and I'm always interested in less overhead. But without those features, its a big-brother v. little-brother competition, and I need the power and protection of the big-brother for now.

But even beyond that, the memory use in the upcoming version of BNT (Proton Pack) just isn't a serious concern. Its smaller than most other webgames, the design is fairly modular, and its getting better every day. There is a reason why "Premature optimization is the root of all programming evil".. in BNT's case, its not a significant issue yet.

I still keep a close eye on adodb-lite however.. maybe it will one day be attractive enough to switch to it.

Posted: Tue Nov 15, 2005 1:58 pm
by Maugrim_The_Reaper
Guess we differ there then, I don't use all the features or if I need some select few (Perf logs spring to mind of course) I can just switch in ADOdb for a production run.

Not that I have a production run... QS is still embryonic...
BDKR wrote:That sounds kinda Golden Hammerish if you ask me. In this case a "smaller is better" mantra could lead to more code in the long run as you try to make up for the lack in the library you chose to start with initially if you faile to accurately identify requiements.
All too true - however the Lite version does meet all my requirements - I don't require the additional features of ADOdb.
BDKR wrote:I do not agree with your contetion that parsing is of little concern.
I didn't make that contention, did I? Posting quickly here so not checking thoroughly. Was making the point (I think) that parsing is not always the overriding factor determining speed. There are dozens of other root causes, and design is often a culprit. A bad design (whether OOP or procedural) can lead to adjustments later on that ruin what optimisation you might have been building in as you coded.

Parsing is a concern - but its one I rarely see in simple black and white. PHP5 is slow and hogs more memory - does that mean I should not use it in favour of the fleeter PHP4?

[edited to fix quotes: Roja]

Posted: Tue Nov 15, 2005 5:05 pm
by AKA Panama Jack
BDKR wrote: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. :oops: 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%.
Now this is the type of discussions I love seeing and being a part of. :D Intelligent, thoughtful and leaving out the nastiness. ;)

Thanks, I am from the old school of programming where speed and memory allocation were the guiding factors. Programs were written to be small and fast with as many features as possible. Sadly I have fallen out of that mindset over the past decade. The work on ADOdb Lite brought that back into focus for me. Actually I wouldn't use the accellerated results as a bases for speed of the code. Not every host is going to offer an accellerator/precompiler for PHP. Plus some of the accellerator packages will optimize the resulting compiled code giving an extra speed boost that normally wouldn't be there.

The non-accellerated ADOdb Lite is only 13% slower than the accellerated ADOdb. If a person wants to focus on speed of execution they should pay more attention to getting the raw PHP code as fast as possible. That will translate into an even bigger boost if the same code is used with an accellerator.
BDKR wrote:"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.

[post cut]

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.

[post cut]

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.
Most of the Benchmark 1 tests were performed using PHP 4.0.6 and there have been substantial changes in PHP since then that may impact on execution speed within objects. The tests I performed were using PHP 4.3.x and 4.4.0 where there were some fundamental changes in how OOP functions, especially with 4.4.0. Even with that testing on both 4.3.x and 4.4.0 resulted in virtually identical pages per second on the same server. Some of the speed differences that John Lim noticed do not appear to be present in the later versions of PHP when using classes.

As an example you can use the Benchmark test from my site to also test the query and record retrieval speed of ADOdb, ADOdb Lite and native PHP functions from 1000 iterations. In the _benchmark.inc.php program change the MAXTIMES to 1000 and run each test.
MySQL: Queried 1000 times for 2.57235789299 seconds

ADODB: Queried 1000 times for 4.06457304955 seconds

ADODB Lite: Queried 1000 times for 3.61717891693 seconds
This is an average of executing each page 10 times and there was a variance of .1-.2 seconds on each page. It looks like the native PHP functions come out on top and that the OOP classes are slower because they are classes. That couldn't be more wrong. The reason is because ADOdb and ADOdb Lite have slightly more code to wade through. Open the _mysql.inc.php program and add the following lines.

Code: Select all

[find]
$rs = mysql_query('select productid,productname,unitsinstock,unitprice from products',$db);

[insert; after]
$currentRow = 0;

[find]
$unitprice=$fields[3];

[insert; after]
if (@$fields == $fields) {
	$currentRow += 1;
}
This will add basically the same extra code that ADOdb Lite and ADOdb executes in the MoveNext function for retrieving the next record with the MySql driver. The result of this change is...
MySQL: Queried 1000 times for 3.80230212212 seconds
Not much different from ADOdb or ADOdb Lite in execution speed. So the execution of functions within a class is not slower than execution of functions outside a class. The speed differences are in the amount of code it takes to accomplish the same objective. Now the reason ADOdb is slightly slower is because of the fact the extension to the ADOconnection class is replacing the default MoveNext function.

So the biggest drawback to using objects in PHP is how fast PHP can create an instance for an object as the execution speeds of the functions inside an object are not reduced compared to a procedural function.

Posted: Tue Nov 15, 2005 5:22 pm
by AKA Panama Jack
Maugrim_The_Reaper wrote:
Basically when it comes to classes in PHP you should avoid creating extensions to a class with functions that replace existing functions in the parent class.
Hmm, what about abstracts under PHP5 then? We can't always sacrifice design for speed without creating problems in other areas. Sometimes the speed penalty is more than outweighed by design considerations... OOP as a practice is the ultimate example - it is slower than matching procedural of course.
Not necessarily... OOP functions can be just as fast as procedural. What you have to stay away from is getting carried away with creating large classes in PHP. The biggest speed draw back is creating a new instance for an object. PHP has to basically allocate memory for the class object and copy the compiled code into that allocated memory. Any extensions that are added onto the class also have to go through this same process. When you have large classes like ADOdb that also have multiple extensions as well as loading in other classes (IE: the time module) then PHP has to allocate a large amount of memory for the object. This is what really slows down everything. If you have a series of small classes then creating the instances for those modules is fairly quick. That's one of the reasons ADOdb Lite is faster. It is a series of small classes and the way the main class is extended is faster. I initially used a method similar to ADOdb for extending the main class and it sucked up memory in a big way.
Maugrim_The_Reaper wrote:However speed is far more likely to be influenced by design, than simple OOP/Procedural parsing differences. The danger with procedural is that growing spaghetti code will result in serious slow downs as "glue" code is added in to combat incompatibilities in the design. A stupidly simple example is a game like Solar Empire (procedural) which crawls against an OOP variant Quantum Star SE - same game in a different package.
That's definately true if the programmer doesn't keep control over the coding. OOP programming can be just as spaghetti ridden as procedural. The difference is the spaghetti code is all lumped into a class. :) I have seen some very well organized procedural code. Our AATraders 0.30 game is still mainly procedural coding with classes mainly used for variable containers. The current 0.30 test version of the game is many times faster and uses far less CPU than the old 0.21 code. I started rewriting just about everything with speed and low CPU load as the basis of the code.

Posted: Tue Nov 15, 2005 5:34 pm
by AKA Panama Jack
BDKR wrote:I do not agree with your contetion that parsing is of little concern. Did you look at the benchmarks on Panama Jack's site? Notice the increase in speed for Adodb when an accelerator was used? The percentage of increase is greater then 3 fold! Parsing makes a huge difference.

Parsing can be a huge and costly operation. There is no way around that fact. Just use an accellerator and be done with it.
This is one of the main problems I have with most programmers today. :) We have the memory and accellerators so who cares about how fast the code is right now. Throw it together and if we need speed make sure the server is using some kind of PHP accellerator. If a programmer is trained to create small and efficient code from the start then they can create the code just as fast if not faster than someone who just goes for what works at the time. Most programmers that are churned out from most courses are not trained in making the code tight and efficient but they are definately trained on making it look PRETTY. That gets my panties in a bunch. ;) You can make the code easy to follow and well laid out while making it tight and fast.
BDKR wrote:The real question comes back to one of mission. Do you need all of that stuff? Are you going to use it? As an example, I just turbocharged one of my cars. I had all the tools I needed to do so. I could've had more tools but I would've suffered a cost in having them for no reason. Not just the initial expense of purchase, but the room they take up? I could've bought a jack hammer, which is a tool, but I wouldn't have used it.

However, if I say, "I need tools for working on my deck, my car, and my roof", it's a good bet that my tool set is going to be a lot bigger. I pay more in the initial purchase and the overhead of housing and maintianing them, but I'll get use out of them which justifies that cost.

So, once the question of mission is out of the way, then you can choose the right tool set and thereby righteously incur whatever issues surrounding parsing overhead and footprint that may insue. At the same time, you will have made a decision to go OO or not (on one level, all of your code should be OO tho you may not use objects proper). In cases concerning application, game, or erp/mrp (as examples) design, OO is the better choice.

Cheers
Well, it's great to have all of those extra tools even if you don't currently need them. And having those extra tools won't slow you down unless you are silly and try to use them all at the same time. That is basically what is happening with ADOdb. It has a ton of tools but they are all combined into one. ADOdb is kind of like a large swiss army knife. A ton of things you can use but they are all crammed into a single tool, one of them gets in the way of doing any one thing well. ADOdb Lite is like a toolbox with a bunch of single tools where you can grab only the tools that you need from it. :)

That's what you need to avoid with classes in PHP. Making that single huge swiss army knife of a class to do everything is a bad thing.