| SitePoint Sponsor |
Maybe you could start a new topic for that?Originally Posted by Andrewaclt
I'm not sure where we've got to in this one. Hopefully we've established that OOP isn't going to slow down your app - although bad code might (even then you'll probably have to try quite hard).
I was kind of interested in the comments about php4 OOP being flawed?
well, the only things that I don't like about php4 OOP include the lack of overloading functions, and then no support for full serialization. I don't know if either of these things have been added in PHP5.
did we ? I saw it as quite possibly the opposite , and here we are now we are talking recursive template parsing and OO producing <tt> tags at runtime ..Hopefully we've established that OOP isn't going to slow down your app
Of course the advantage of reusability and refactoring of OO is massive , but the load is a real issue for an interpreted language.
I use OO , not to the extent or with any way near the skill of most here but I use it none-the-less , what I do not (mostly) use it for is the sharp-end , e.g the bit that your webserver will (hopefully) be parsing many, many times a second .
FUD forum kind of made my mind up for me with pre-'compilation' of templating ,functions for FUD but could just as easily be OO , compliation to HTML that is , or just to simpler static PHP routines , its along the lines of what I have been playing with for a while but it was nice to see someone who knew what they were doing, doing it
My non-OO background means that I am only recently discovering and beginning to understand some of the 'patterns' that are so beloved here , indeed I am already using some of them I just did not realise.
So IMO even accepting ALL of OO's advantages one still has to look at the bigger picture , an interpreted language has certain issues & they need to be addressed.
In some implementations of course it does not matter , my own code/framework generators are slow and heavy and full of hacks and some simply awful code , BUT , the code they generate is fast & compact & stands half a chance on a busy server , I don't care how slow the generators are but I do care about how fast the output/result is.
Thanks
Pretty much sums it all upSo what you do is make a template out of templates?
Much as what I've done, basically it just fetches the required template file, with a class method to replace a given tag with data, and when required, return the template file it's self, back to the Viewand then create a Fragment class.
Now I'm reading Advanced PHP Programming so I can try to work out the best approach to cache the templates ?
But I'm still thinking just what should I cache ?
* the semi complete template which is built up via the template fragments that are non dynamic, or
* cache each template fragment as it is, dynamic or not, which are fetched (if exists) instead of generating the template ?
With the approach I have, it offers a lot of flexibility, though there can be a lot of file includes which I'm thinking may be unwarranted overhead, so caching will help considerably (I hope).
But, yes, post your new script when you've finished and ran some tests with it, and I'll see what I think of it tomorrow
Would be interesting to see what you come up with
The way i had planned on implementing caching was taking a serialized version of the object, and saving it in the database. Then, when the script is run, I just check if the cache is less than, say 5 minutes old, and if so, just unserialize the object and call the show() method(yes i know this can have "unpredictable" results, but i'm praying that full serialization will be one day available. That and when i did it in a PHP-GTK app, it has worked everytime perfectly as expected.)
Yeah I'll be sure to work on it.
OO Programming offers a lot of advantages which I'm not going to go into as you should by now know of themHopefully we've established that OOP isn't going to slow down your app
But in my view, using OO does offer very good performs in regards to server performance <> page hits ratio
What overheads there are, the advantages of using OO far outways the disadvantages, if there are in fact, any ?
All this talk about OO being slow is basically all bulls*** as at the end of the day, you'll not do a better job of an OO driven application with plain procedural programming, and I'll defy anyone to say differently
So just sit back, relax and enjoy the finer things OO offers
PHPversion5 has I think, better serialisation which I'm looking forwards to
I still need to run some benchmarks on my scripts, nothing too intensive though, just seeing how long it'd take to render an average page
For example, comparing building a single template fragment against a (test) template fragment to be inserted into the template shell.
If there is a big difference, (like, is it going to be worthwhile?) then I'll opt for the first option.
Hi...
In the more advanced category (which I think is what you want)...
Roles, Responsibilities and Collaborations - Rebecca Wirfs-Brock
This can be a bit stodgy, but everything she says always turns out right once you try it.
Agile Software Development - Robert Martin
Lot's of stuff here, some of it more controversial
Domain Driven Design - Eric Evans
How to build high level object models from requirements and keep them on track.
Object Oriented Software Construction - Bertrand Meyer
Low level stuff with plenty of definitions. More academic in style.
Also check out the C2 wiki and The Pragmattic Programmer by Hunt and Thomas.
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
Hi...
@firepages: Yours is a good post. My comments aren't aimed at you, it's just that you have nice juicy quotable bits...
I don't think we have established anything. We won't without more infomation.
The load from an interpreted language will be high if not much else is happening within a script. Parsing is an example where a lot of calculation happens and where an interpreted language hurts. It doesn't matter whether it is OO or not. Look at a "functional" language like XSLT - hardly a speed demon. For that matter try writing code in Lisp or Prolog or Awk.
Yes
Code generation is a good way of optimising sections of code, effectively unrolling some of the logic. This is especially effective in PHP when combined with a bytecode cache. We use it in a few places.
The tricky bit is getting the order right. Code generation is complex, putting another layer and language between you and the final output. It makes maintanence that bit harder. You really need the code generated section tucked away behind an effective interface. Once isolated it can perform it's magic without damaging the rest of the code base.
In order to get this level of isolation you will have to start from a well factored design. This is the nub. There are two times to think about optisations (such as code generation). Once at the beginning to decide if the whole application approach is feasable (back of envelope stuff) and again towards the end (the real engineering work). The bit in the middle should just be designed well, without regard to performance. Once it's well factored, then optimise.
How much did your code generation buy you? A factor of two at least, right? Say OO slows the code down by a third (unlikely in my experience) assuming you ignore the positive performance impact it has on the client code. If OO gives you the option to employ a generation solution without cutting across the codebase, you are still winning by a massive margin when you switch to OO. This kind of improvement is typical.
That's why, once you start optimising for real, OO codebases usually win in the end for performance. They enable more radical solutions.
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
No. I think you've missed my point, here: The 'trap' behing PHP4+OO is that you have to learn 'special' skills to do OOP in PHP4. Not just 'learn how to do OO', but 'Learn how to do OO in such a way that your internal OO-bogometer does not explode, and at the same time PHP4 performance isn't terrible.'
That's a tall order in its own right. The general lameness of PHP4's OO implementation doesn't help.
FWIW, I'm exploring PHP5 right now. It's like running out of the men's locker room onto the floor of a stadium -- the air is fresh, the sun is shining, the crowd is cheering, and the cheerleaders are naked. (Well, they are in my mind...)
=Austin
(I have no performance opinion on PHP5 yet.)
The one where he says this, about two sentences above the code?
Yeah, it violates a lot of things. But it's a primer in PHP syntax. Give a writer a break, eh?
=Austin
In the United States right now there are about 40 million Demicans running around saying 'John Kerry is going to be the next president!'. There are likewise about 40 million Republocrats running around saying 'George Bush is going to be the next president!'
Sometime in November (God willing!) there will be 40 million disappointed people. Saying a thing over and over doesn't make it true.
(I will grant that OOP is, to paraphrase WLSC, the best form of the worst kind of development.)
=Austin
Let's not forget the basics:
Object-Oriented Design, Grady Booch
A disproportionate amount of what he wrote is still relevant. Keep in mind that the original version (it has been updated a few times) was one of the founding works of the OO space.
If you can find one of the versions where he compares Ada against Common Lisp (CLOS), take a look at the comparison appendices -- it's right in line with this thread, discussing dispatch costs versus dynamism.
=Austin
Hi,
My take on this is that a script written in a procedural style will execute faster than a script written with an OO style 99% of the time. However a programmer should be able to write many more scripts using OO than writing Procedural in the same amount of time.
An example:
This is how I would write a script to display a list of articles using a procedural style.
Fairly basic, no surprises. Couldnt really get this run much faster.PHP Code:<?php
if (!$conn = @mysql_connect('localhost', '', '')) {
trigger_error('Invalid database connection settings');
} elseif (!mysql_select_db('article', $conn)) {
trigger_error('Invalid database name');
}
$sql = 'SELECT id, title, content, author, date FROM article';
if (!$resource = @mysql_query($sql, $conn)) {
trigger_error('Invalid query : ' . $sql);
}
?>
<html>
<head>
<title>Article List</title>
</head>
<body>
<h1>Article List</h1>
<?php if (mysql_num_rows($resource) == 0) { ?>
<p>There are no articles.</p>
<?php } else { ?>
<table>
<tr>
<th>Title</th>
<th>Author</th>
<th>Date</th>
<th>Action</th>
</tr>
<?php while ($record = mysql_fetch_array($resource, MYSQL_ASSOC)) {?>
<tr>
<td><?php echo $record['title']; ?></td>
<td><?php echo $record['author']; ?></td>
<td><?php echo $record['date']; ?></td>
</tr>
<?php } ?>
</table>
<?php } ?>
</body>
</html>
Now if I add a data access layer, I dont have to worry about mysql connections and errors on every page. I can also change the database without going through every page on my site and changing every line with a mysql function.
This script is now takes marginally longer to execute however, I can write it marginally faster. The time saved adds up over the amount of pages in the application.PHP Code:<?php
require_once('MySqlDataAccess.php');
$dbConn = &new MySqlConnection('localhost', 'article', '', '');
$sql = 'SELECT id, title, content, author, date FROM article';
$recordSet = $dbConn->executeQuery($sql);
?>
<html>
<head>
<title>Artile List</title>
</head>
<body>
<h1>Article List</h1>
<?php if ($recordSet->size() == 0) { ?>
<p>There are no articles.</p>
<?php } else { ?>
<table>
<tr>
<th>Title</th>
<th>Author</th>
<th>Date</th>
</tr>
<?php while($recordSet->next()) { ?>
<tr>
<td><?php echo $recordSet->get('title'); ?></td>
<td><?php echo $recordSet->get('author'); ?></td>
<td><?php echo $recordSet->get('date'); ?></td>
</tr>
<?php } ?>
</table>
<?php } ?>
</body>
</html>
Ive noticed that I use the same sql query to get the article list on many pages. So I add a Data Source layer, and I can call a function on an object each time I need the list of articles.
I replace this code:
with this code:PHP Code:require_once('MySqlDataAccess.php');
$dbConn = &new MySqlConnection();
$sql = 'SELECT id, title, content, author, date FROM article';
$recordSet = $dbConn->executeQuery($sql);
The page is now marginally slower to execute.PHP Code:require_once('ArticleTableDataGateway.php');
$articleTDG = &new ArticleTableDataGateway();
$recordSet = $articleTDG->findAll();
Now I notice that each page of my site uses the same structure (dtd, head, meta tags, nav etc) for the html page. So I decide to add a template structure/engine.
The code now looks like this:
Ill leave the templates to the imagination.PHP Code:<?php
require_once('ArticleTableDataGateway.php');
$articleTDG = &new ArticleTableDataGateway();
$recordSet = $articleTDG->findAll();
$tpl = new Template('main.tpl', 'article_list.tpl');
$tpl->set('title', 'Article List');
$tpl->set('recordSet', $recordSet);
$tpl->render();
?>
The page runs slower again, but I now can use the main.tpl for every page.
I could continue on with more to add to this that will make building a website easier and quicker to do but in the end it will always be slower to execute the script. For me, the development time saved orginally, when you want to add features and when bugs appear outweighs the difference in execution time of the script.
Note: caching this page would now be quite easy. Using a cache in php when using OO will make up for any difference in execution speed.
Yes, thats the beauty of templates, and if you look at what Widow Maker and I were discussing earlier, the code for a Template engine that works in a very similar fasion is posted. That said I still wouldn't want people to steal my code, its posted for reference purposes, to see how someone else did it. That and if it wasn't mine, I wouldn't really want to use my own code.
Widow Maker--Upon re-rereading, I saw that you are using the MVC pattern. I don't personally like this pattern in PHP, because there is so little for the controller to do(just creates objects for you in your example), and the code in the execute() function seemed to be very static(would require minor edits with each site). I believe that in this case, MVC just adds an unnecessary layer of complexity by introducing another object & function interface and moving the new operator into another function. I would personally prefer to just create the object myself rather than have the controller class do it and return it, or if perhaps there is some sort of batch work(ie lines of initialization calls that are always the same) that I can assign to it, then I might consider using it. But if I will always have the same init calls, why not just put them in constructor?
I was asking for clarification and asking for an example of what would be a good method for this, I know hardly anything beyond basic oop concepts and was just trying to figure out were to go next...
It wouldn't be fair to compare an OOP solution with lots of extra features with a simple procedural one without these features - perhaps that's not what you intended.
For example, you'd have to compare a non-OOP db layer (implemented with simple fn wrappers) to one implemented with OOP. It should be obvious, given both are well-written, that any differences would be minute (and completely overwhelmed by query execution times).
In any case it's not that simple, as Lastcraft has pointed out.
Not what I indended. In the simple example I gave using OOP will be minutely slower even if you only add the minimum amount for the code to run to the db wrapper etc.
I realize that whats being discussed is more along the lines of complex domain/application logic. I would think that alot of the time the same theory will apply though, that using OO will minutely increase the execution time although significantly decrease the development time.
That said, Ive never tested this going from a complex procedural script to a complex OO script. I guess Marcus' experience with OO being faster would have to do with procedural code creating new variables in memory where the OO version didnt..? Somehow the procedural version called more functions? I can see how OO would be faster than procedural but am having a hard time writing code to reproduce it. What are the circumstances that cause OO to be faster?
Either way no one should be writing complex scripts using a procedural style so you can get what you think will be a performance gain. Write it using OO and defactor it if you need to. (When I say defactor I mean the opposite of refactor. What would the correct term be?) It will kick you in the *** writing procedurally later when you want to change it, you will have more bugs, and it will take longer.
Everything youre saying about PHP4 I would apply to writing OO with PHP5. You can bloat the php5 code as much as you can with php4 although php5 will handle it better.
]
Unfortunately, PHP5 stiil doesn't support function overloading
Yes it does, you just have to know how...
Ryan
If you mean something like this:
Then PHP 4 also supports thatPHP Code:class SomeClass
{
function someMethod ()
{
switch ( func_num_args () ) {
case 1:
return _someMethod1 ( func_get_arg ( 0 ) );
break;
case 2:
return _someMethod2 ( func_get_arg ( 0 ), func_get_arg ( 1 ) );
break;
}
}
}
Hi...
'Fraid not. If you do milisecond timings you will probably find that accessing a global is faster than a static which is faster than a static function return. Isolated this way it will be a factor of two or more slower. Isolating it in this way is pretty dumb though. One point is that this is totally swamped by the script loading time at least.
If OO causes you to write less code then you actually win even on this. Initially OO code is about 15% bigger, but the higher level of factoring starts to kick in once the client code is using the classes. Unfortunately the higher level of factoring also means that you will likely require more files for a simple script. I think this is why the heavier OO users also favour bytecode caching solutions or are very careful about their require_once's.
The script execution time is almost always swamped by file access and DB access calls. They in turn will get swamped by network calls. For a script to do anything useful you would have several of these and speeding these up will produce a bigger win.
OO makes it easier to factor the code. Better factored code makes it easier to employ caching, code generation, lazy loading, query batching, adding C modules, replacing slow subsystems, lookup tables, load balancing, DB caching and...er...being careful about your require_once's. All of these will give order of magnitude improvements if they are the current bottleneck.
If you want to optimise a system, rather than just tweak source code, you want to do it from an OO codebase. That's why OO code ultimately wins.
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
No support for multiple contructors then?If you mean something like this:
Then PHP 4 also supports that
Yeah....thats too hackish for me....I would really prefer being able to have something more like this:
You know, real function overloading.PHP Code:class SomeClass {
function SomeClass($a, $b, $c) {}
function SomeClass($a) {}
function SomeClass($a, $b) {}
}
By the way, I changed my mind about the Controller class. I will have one, but it won't be solely to control my Template & Fragment classes. I have a static method in a User class that I wrote, that I feel would fit better in a controller class, because it's only purpose is to construct the User class in a certain way. I'll probably find other things to do with it too, I'm sure there'll be a lot for me to control once I take these classes past the "design objects for various uses" stage and utilize them in a project of sorts. I still don't like MVC very much, nor do I really see its purpose in PHP, but I figure "everyone else uses it, theres gotta be a reason?"
Hi...
I also forgot Refactoring by Martin Fowler (doh).
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
Posting Permissions
Bookmarks