[PHP] Re: PHP OOP x Procedural Performance
William N. Zanatta [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] It is a known issue that function calls are expensive for the processor. The OOP let us better organize the code but, thinking in function (or method) calls it may be more expensive than in the procedural form. My question is, has anyone made any tests regarding the performance of OOP versus procedural language? Is it a good choice to code in OOP with PHP ? I would say, that web app model is so inefficient in itself, that you can hardly do anything to make things significantly worse or better performance wise. Also OOP is extensively used in other environments, and unless you are coding critical device drivers, it is rarely to expensive in terms of processing time. So my advice would be use OOP, and take benefit of better organization of your code. Just my 2c. rush -- http://www.templatetamer.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP OOP x Procedural Performance
In my experience OOP isn't any faster/slower. I've used it on sites that get 30M hits a month; so if it's gonna break I'd have seen it by now. One thing I'd like to abundantly point out is that NOT EVERYTHING BELONGS IN OOP! For instance, if you're building classes that output HTML - you've skipped a few chapters in your OOP design books. OOP with PHP is lacking as far as complex application development (PHP5 looks to fix this), but it works great for base classes. I usually program CORE functionality in OOP (ie. Basket for e-commerce which keeps track of users' baskets). The rest of the code is procedural (ie. code that does basic math and organizes the page). --Joe -- Joe Stump [EMAIL PROTECTED] http://www.joestump.net Label makers are proof God wants Sys Admins to be happy. -Original Message- From: rush [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 8:02 AM To: [EMAIL PROTECTED] Subject: [PHP] Re: PHP OOP x Procedural Performance William N. Zanatta [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] It is a known issue that function calls are expensive for the processor. The OOP let us better organize the code but, thinking in function (or method) calls it may be more expensive than in the procedural form. My question is, has anyone made any tests regarding the performance of OOP versus procedural language? Is it a good choice to code in OOP with PHP ? I would say, that web app model is so inefficient in itself, that you can hardly do anything to make things significantly worse or better performance wise. Also OOP is extensively used in other environments, and unless you are coding critical device drivers, it is rarely to expensive in terms of processing time. So my advice would be use OOP, and take benefit of better organization of your code. Just my 2c. rush -- http://www.templatetamer.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP OOP x Procedural Performance
One thing I'd like to abundantly point out is that NOT EVERYTHING BELONGS IN OOP! For instance, if you're building classes that output HTML - you've skipped a few chapters in your OOP design books. Joe, I am curious about this opinion, could you elaborate a bit, please? I am not an OOP programmer, and I'm just interested in your thoughts on this, if you have time. Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP OOP x Procedural Performance
Sure ... I'm of the belief that OOP (in PHP anyways) has great use for core libraries. Core libraries, by their nature, generally don't output HTML. It's a core libraries job to separate logic and presentation. How portable is your library that outputs HTML for a guy who wants PDF/WAP/XML output? For instance, I have a product class that does various things to format product *data* prior to my procedural scripts putting it into my Smarty templates. If that product class outputted the data in HTML it would be useless to me for WAP users or a script that generated PDF versions of our online catalog. --Joe -- Joe Stump [EMAIL PROTECTED] http://www.joestump.net Label makers are proof God wants Sys Admins to be happy. -Original Message- From: Johnson, Kirk [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 8:21 AM To: 'Joe Stump'; [EMAIL PROTECTED] Subject: RE: [PHP] Re: PHP OOP x Procedural Performance One thing I'd like to abundantly point out is that NOT EVERYTHING BELONGS IN OOP! For instance, if you're building classes that output HTML - you've skipped a few chapters in your OOP design books. Joe, I am curious about this opinion, could you elaborate a bit, please? I am not an OOP programmer, and I'm just interested in your thoughts on this, if you have time. Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP OOP x Procedural Performance
Joe, I mostly agree with your opinion. But remember that a method in an object that has output doesn't have to print the output - it can return it instead and the calling function can then either display the output or do something else with it. And if it makes sense to have a method return HTML, another developer can override that method so that it returns XML. Or yet another method could take the HTML output of the first one and convert it to PDF. The question, I think, is about figuring out the most effective place to do what solves the problems. I'm afraid that saying You should never ever ever write an OOP method that has HTML in it's output is so rigid that it might make the development process more difficult and complex than it needs to be. Michael On Thu, 2003-05-29 at 11:28, Joe Stump wrote: Sure ... I'm of the belief that OOP (in PHP anyways) has great use for core libraries. Core libraries, by their nature, generally don't output HTML. It's a core libraries job to separate logic and presentation. How portable is your library that outputs HTML for a guy who wants PDF/WAP/XML output? For instance, I have a product class that does various things to format product *data* prior to my procedural scripts putting it into my Smarty templates. If that product class outputted the data in HTML it would be useless to me for WAP users or a script that generated PDF versions of our online catalog. --Joe -Original Message- From: Johnson, Kirk [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 8:21 AM To: 'Joe Stump'; [EMAIL PROTECTED] Subject: RE: [PHP] Re: PHP OOP x Procedural Performance One thing I'd like to abundantly point out is that NOT EVERYTHING BELONGS IN OOP! For instance, if you're building classes that output HTML - you've skipped a few chapters in your OOP design books. Joe, I am curious about this opinion, could you elaborate a bit, please? I am not an OOP programmer, and I'm just interested in your thoughts on this, if you have time. Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP OOP x Procedural Performance
Joe Stump [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Sure ... I'm of the belief that OOP (in PHP anyways) has great use for core libraries. Core libraries, by their nature, generally don't output HTML. It's a core libraries job to separate logic and presentation. How portable is your library that outputs HTML for a guy who wants PDF/WAP/XML output? For instance, I have a product class that does various things to format product *data* prior to my procedural scripts putting it into my Smarty templates. If that product class outputted the data in HTML it would be useless to me for WAP users or a script that generated PDF versions of our online catalog. Core libraries are of course first candidate for OOP, but I think there are many other places where you can use it successfully. Take for instance how it is used in TemplateTamer. In it, you define a class responsible for the generation of the page. In typicall usage you have a common class that all page classes inherit from, and which defines elements of page common to all pages on the site, and specific page classes implement only the parts they differ in. When the site grows, it is common to refine the hierarchy of page classes, so you have one page class on the top, then a few below it describing main sections of the site, and then on the bottom concrete page classes. Another OOP usage in TT can be in creating classes that represent GUI components. For instance on one site I have worked, I have created a JobAdForm object, that handles for reponsible displaying form and editing of JobAd object. Than when I needed similar but litle more extended version for superuser pages, I have just created a subclass SuperuserJobAdForm, and overided necessary parts, but inhertied 95% of code. So I think there is usage for OOP also in gui parts of the code, where it can also help better organization of code, and reuse between the pages or components on the same site. rush -- http://www.templatetamer.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP OOP x Procedural Performance
Hi, From my personal recent experience, I can tell you that processing a lot of echo's thru classes is a heck of a lot slower than just doing it the normal way. Although I wouldn't have done this particular project any other way, I do with that I could get it to display faster. Its not a big deal, just bugs me. Its really personal preference though. -Dan Joseph -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
