Re: [PHP] Objects and Performance
On 6/8/05, Greg Beaver [EMAIL PROTECTED] wrote: If you want to compare object methods versus functions, you should compare identical code inside a method to code inside a function. Greg's benchmarks compare two different ideological code structures. Quite honestly, the wrapping of mt_srand() inside a function or method does not satisfy the definition of good coding, object-oriented or otherwise. Functions/methods should be used to abstract common operations. mt_srand() already does this necessary abstraction, and putting a further wrapper around it makes no sense. I called mt_srand() inside the constructor, so it's only called once, same as the procedural version. This being an example of a class, it seems like the logical place to put it. I can remove it from both versions but it's not gonna change much as far as speed. If your code does simple operations on a few operands and returns a value, like our mt_srand() function, there is absolutely no point in making it more complicated. I agree. In the real world a given task will likely be more complicated, but that's not the point here. However, you could consider wrapping the functions inside a class and using them as static methods. There is little point in making classes to then only use the methods statically. You could just put all your similar functions in an include file and be done with it. Nothing more annoying than working on someone else's OO code and seeing Foo::bar() all over the place. Pointless. This would essentially give them a namespace that would allow any conflicts with other programmer's function names to be more easily resolved. If PHP needs namespaces then add them, last I heard the consensus was that it didn't. I've never needed them personally. It doesn't seem like enough justification to use objects just because you don't want to rename a few functions in the rare event you actually have a conflict. Seriously, how many times have you been working on a PHP project that was so big, with so many developers, that you bumped into each other with function names? Has yet to happen to me. In other words, renaming a class is a whole lot simpler than renaming a function (think search-and-replace ClassName:: versus functionprefix_ - the second one might inadvertantly replace variables, etc., but the first is unusual syntax) Renaming anything is simple when you use good tools. for file in *.php; do cp $file $file.tmp sed -e s/foo\(/prefix_foo\(/g $file.tmp $file rm $file.tmp done make the code readable and maintainable and it will cut down on bugs and work better than faster code. I always value efficient code over time to code. Doing more with less hardware should always be a programmer's first goal in my opinion. The overhead involved in bringing a web-based object into existence for the extremely short period of time it will live can never justify the 'maintainability' and 'readability' arguments I'm always hearing preached. I've never seen any OO PHP code that was easier to read or maintain for that matter. -- Greg Donald Zend Certified Engineer http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Objects and Performance
* Greg Donald [EMAIL PROTECTED] : On 6/8/05, Greg Beaver [EMAIL PROTECTED] wrote: If you want to compare object methods versus functions, you should compare identical code inside a method to code inside a function. Greg's benchmarks compare two different ideological code structures. Quite honestly, the wrapping of mt_srand() inside a function or method does not satisfy the definition of good coding, object-oriented or otherwise. Functions/methods should be used to abstract common operations. mt_srand() already does this necessary abstraction, and putting a further wrapper around it makes no sense. I called mt_srand() inside the constructor, so it's only called once, same as the procedural version. This being an example of a class, it seems like the logical place to put it. I can remove it from both versions but it's not gonna change much as far as speed. If your code does simple operations on a few operands and returns a value, like our mt_srand() function, there is absolutely no point in making it more complicated. I agree. In the real world a given task will likely be more complicated, but that's not the point here. Actually, that is the point. What Chris was getting at is that usually you have a bit more going on in a function or method -- several operations, not just a wrapper for a single operation -- that the function/method call serves to abstract. So, calling a method that simply calls and returns a single php internal function call isn't going to give a good comparison; we already know that calling the function is faster. However, you could consider wrapping the functions inside a class and using them as static methods. There is little point in making classes to then only use the methods statically. You could just put all your similar functions in an include file and be done with it. Nothing more annoying than working on someone else's OO code and seeing Foo::bar() all over the place. Pointless. Unless you have several function libraries that were developed separately and *do* have the same function names. Where I work, for instance, at one point we had three function libraries, developed separately, that each had their own 'send' function, which worked fine until we tried to develop an application that mixed some functionality from the different libraries. Granted, we could have refactored and split out the common functionality from the libraries into a separate library, but we found it was much easier to wrap everything into classes and uses the class structure as a namespace. (We've since completely refactored and gone all OOP, but that's neither here nor there.) This would essentially give them a namespace that would allow any conflicts with other programmer's function names to be more easily resolved. If PHP needs namespaces then add them, last I heard the consensus was that it didn't. I've never needed them personally. It doesn't seem like enough justification to use objects just because you don't want to rename a few functions in the rare event you actually have a conflict. Seriously, how many times have you been working on a PHP project that was so big, with so many developers, that you bumped into each other with function names? Has yet to happen to me. That's *your* experience. You're going to keep seeing namespace discussions pop up whenever other people have experiences that indicate namespaces would help solve the issue. You're also going to have the issue pop up whenever you have developers from other languages start using PHP. I come from a perl background; I'd *love* to have namespaces in PHP... but I can use classes to emulate them fairly well. snip make the code readable and maintainable and it will cut down on bugs and work better than faster code. I always value efficient code over time to code. Doing more with less hardware should always be a programmer's first goal in my opinion. The overhead involved in bringing a web-based object into existence for the extremely short period of time it will live can never justify the 'maintainability' and 'readability' arguments I'm always hearing preached. I've never seen any OO PHP code that was easier to read or maintain for that matter. Again, your experience. I *have* seen OOP PHP that was easier to read and maintain. I've seen (and written) some perfectly horrendous procedural code that was a nightmare to read and maintain. You're right -- you should try to write efficient code. But sometimes you have to look at programmer efficiency as well -- if you're working for a client under a deadline, you don't always have that luxury. -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association| http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:[EMAIL PROTECTED] | http://vermontbotanical.org -- PHP
Re: [PHP] Objects and Performance
On 6/9/05, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote: Actually, that is the point. If I decide the write a script, and it is my idea, then the point of the script is my own. It's a simple benchmark. I doubt a client would ever come to me and say Can you write me a script to add two random numbers a thousand time? No, it's not gonna happen. I decided what the benckmark would do, and so I wrote it. I wrote two versions, a full-on OO version, and a pure procedural one. _That_ is the point of the benchmark. What do you not grasp about that? What Chris Chris who? was getting at is that usually you have a bit more going on in a function or method -- several operations, not just a wrapper for a single operation -- that the function/method call serves to abstract. If you think it matters a great deal rewrite the benchmark and remove it. The OO version will still be slower. Putting a single function call in a wrapper function is better known as 'abstraction'. If later I decide to use srand() instead of mt_srand() I only have to change it in one place. if you're working for a client under a deadline, you don't always have that luxury. Exactly why I always write procedural style. It's much faster to code, to run, and to debug. -- Greg Donald Zend Certified Engineer http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Objects and Performance
On 6/8/05, NSK [EMAIL PROTECTED] wrote: Hi, I am creating a small API in PHP, i.e. a collection of reusable functions for other programmers. As it is now, it is just many functions together in the same file. Do you think I should make it object-oriented? What are the pros and cons of this approach in PHP? I am particularly very concerned about performance. Are object methods slower than functions in php? Definitely not scientific but have a look: http://destiney.com/Benchmarks -- Greg Donald Zend Certified Engineer http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Objects and Performance
Greg Donald wrote: On 6/8/05, NSK [EMAIL PROTECTED] wrote: Hi, I am creating a small API in PHP, i.e. a collection of reusable functions for other programmers. As it is now, it is just many functions together in the same file. Do you think I should make it object-oriented? What are the pros and cons of this approach in PHP? I am particularly very concerned about performance. Are object methods slower than functions in php? Definitely not scientific but have a look: http://destiney.com/Benchmarks If you want to compare object methods versus functions, you should compare identical code inside a method to code inside a function. Greg's benchmarks compare two different ideological code structures. Quite honestly, the wrapping of mt_srand() inside a function or method does not satisfy the definition of good coding, object-oriented or otherwise. Functions/methods should be used to abstract common operations. mt_srand() already does this necessary abstraction, and putting a further wrapper around it makes no sense. Nobody can give you a good answer to your question without seeing the specific code. If your code requires a lot of global variables in order to operate, you might consider abstracting this into a class. Also, if you find yourself creating several copies of the same variables, use classes in order to allow two incarnations of the code to exist in the same file as objects. If your code does simple operations on a few operands and returns a value, like our mt_srand() function, there is absolutely no point in making it more complicated. However, you could consider wrapping the functions inside a class and using them as static methods. This would essentially give them a namespace that would allow any conflicts with other programmer's function names to be more easily resolved. In other words, renaming a class is a whole lot simpler than renaming a function (think search-and-replace ClassName:: versus functionprefix_ - the second one might inadvertantly replace variables, etc., but the first is unusual syntax) So, in short, analyze the problems your code solves, and see if they would be better solved by abstracting into classes, or by keeping the code as functions. Forget about minor performance differences from program syntax unless you're writing code for a site with thousands of hits per second. In that case, you'll want to use a profiler like APD to find the real bottlenecks in your code. Otherwise your main inefficiency is going to be programmer time rather than processor time: make the code readable and maintainable and it will cut down on bugs and work better than faster code. Greg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
