Comments on: 10 more tips to make your PHP application scream - Part 2 of N http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/ A blog about killer code Thu, 28 Aug 2008 02:35:50 +0000 http://wordpress.org/?v=2.5.1 By: jaisen http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-43 jaisen Mon, 03 Mar 2008 19:28:56 +0000 http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-43 @Chad - You bring up a good point. I hadn't thought about including an article in the series which talks about writing easy to read/maintainable code - which in some cases conflicts with some of these suggestions. For a PHP application to scale it needs to be easy to follow the code for current and new developers. That's often overlooked and time IS money - I'll work that into the series. I should add a note to the beginning of each article which explicitly states to not blindly follow any tips mentioned below - but rather assess the pros and cons of each and implement accordingly. Additionally, I'm a huge proponent of Agile development and not over engineering early in the development process. Generally...bottlenecks are best addressed once they begin to creep up. With easily managed code addressing them should be quick. @Chad - You bring up a good point. I hadn’t thought about including an article in the series which talks about writing easy to read/maintainable code - which in some cases conflicts with some of these suggestions. For a PHP application to scale it needs to be easy to follow the code for current and new developers. That’s often overlooked and time IS money - I’ll work that into the series.

I should add a note to the beginning of each article which explicitly states to not blindly follow any tips mentioned below - but rather assess the pros and cons of each and implement accordingly.

Additionally, I’m a huge proponent of Agile development and not over engineering early in the development process. Generally…bottlenecks are best addressed once they begin to creep up. With easily managed code addressing them should be quick.

]]> By: Chad http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-42 Chad Mon, 03 Mar 2008 19:23:57 +0000 http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-42 Oh, well I just read your front page and see you develop for Yahoo! I guess your apps are guaranteed to need scale, which changes things substantially. But for the average joe, like me, don't worry about scale until you need to. Chances are your won't. Oh, well I just read your front page and see you develop for Yahoo! I guess your apps are guaranteed to need scale, which changes things substantially.

But for the average joe, like me, don’t worry about scale until you need to. Chances are your won’t.

]]> By: Chad http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-41 Chad Mon, 03 Mar 2008 19:14:43 +0000 http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-41 I totally agree that these tips are best practices if not great performance boosters. However, to me it's more about going forward with a uniform practice that increases readability, performance, and reduces the need for refactoring. I don't see going backwards for these gains. Let's take wordpress, which has some pretty ugly source code and refactor it. That would take several man-hour days just to read through all of the source code, plus fixing the code. In the end, you maybe save a few tenths/hundredths of a second and you would have been better off investing your money (since time=money) in another server, bigger VPS, etc. It's kind of the Rails mantra, keep throwing machines at the problem until it become worth your time to fix. Most applications never need this scale, but it's good practice to use going forward. I totally agree that these tips are best practices if not great performance boosters.

However, to me it’s more about going forward with a uniform practice that increases readability, performance, and reduces the need for refactoring.

I don’t see going backwards for these gains. Let’s take wordpress, which has some pretty ugly source code and refactor it. That would take several man-hour days just to read through all of the source code, plus fixing the code. In the end, you maybe save a few tenths/hundredths of a second and you would have been better off investing your money (since time=money) in another server, bigger VPS, etc.

It’s kind of the Rails mantra, keep throwing machines at the problem until it become worth your time to fix. Most applications never need this scale, but it’s good practice to use going forward.

]]> By: jaisen http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-40 jaisen Mon, 03 Mar 2008 09:17:47 +0000 http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-40 @Chad, Thanks for writing the benchmarking script. I've updated the post to include them in the "resources". I agree with you that the performance gains are slight. While it's rare that site will see the benefit of this it's good to write code knowing what PHP is doing under the hood. Minimizing function calls, bypassing the regular expression engine and ordering conditional statements is just good programming practice. It would be a waste of time to refactor an entire application using these principles. There's almost always more bang for your buck elsewhere. Generally at the database...which will be it's own part in this series. It's important to remember that PHP alone doesn't make a site fast or scale..it's a combination of several things --- which is what I hope to touch on in this series. @Chad, Thanks for writing the benchmarking script. I’ve updated the post to include them in the “resources”.

I agree with you that the performance gains are slight. While it’s rare that site will see the benefit of this it’s good to write code knowing what PHP is doing under the hood. Minimizing function calls, bypassing the regular expression engine and ordering conditional statements is just good programming practice.

It would be a waste of time to refactor an entire application using these principles. There’s almost always more bang for your buck elsewhere. Generally at the database…which will be it’s own part in this series.

It’s important to remember that PHP alone doesn’t make a site fast or scale..it’s a combination of several things — which is what I hope to touch on in this series.

]]> By: Chad http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-39 Chad Mon, 03 Mar 2008 07:37:28 +0000 http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-39 I wrote a benchmarking script, the results are extremely negligible for most purposes. It's on my blog.. http://conductr.com/ I wrote a benchmarking script, the results are extremely negligible for most purposes.

It’s on my blog..
http://conductr.com/

]]> By: jaisen http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-33 jaisen Sat, 01 Mar 2008 17:58:01 +0000 http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-33 @Kevin, Good point. I added a note about that and changed my example. @Kevin, Good point. I added a note about that and changed my example.

]]> By: jaisen http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-32 jaisen Sat, 01 Mar 2008 17:43:10 +0000 http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-32 @Amit, Thanks for the note. I made an update to the post noting what you said. @Amit, Thanks for the note. I made an update to the post noting what you said.

]]> By: Kevin http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-31 Kevin Sat, 01 Mar 2008 14:48:27 +0000 http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-31 Using {} to access a string as an array is deprecated as of PHP 6. Since it is an array it makes more sense to use the [] anyway. $string[3] Using {} to access a string as an array is deprecated as of PHP 6. Since it is an array it makes more sense to use the [] anyway. $string[3]

]]> By: Kevin http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-30 Kevin Sat, 01 Mar 2008 14:45:38 +0000 http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-30 Another thing to note is that you have to use the double quote if you want to use an escape sequence, such as \n. You can still have your performance gain by mixing quotes: 'Hello, my name is ' . $name . "\n" Another thing to note is that you have to use the double quote if you want to use an escape sequence, such as \n. You can still have your performance gain by mixing quotes: ‘Hello, my name is ‘ . $name . “\n”

]]> By: Kevin http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-29 Kevin Sat, 01 Mar 2008 14:40:51 +0000 http://www.jaisenmathai.com/blog/2008/02/29/10-tips-to-make-your-php-application-scream-part-2-of-n/#comment-29 I'd like to see some actual benchmark tests you've run with results graphed accordingly to show just how much faster each tweak is and when it is beneficial to use it and not really worth it. I’d like to see some actual benchmark tests you’ve run with results graphed accordingly to show just how much faster each tweak is and when it is beneficial to use it and not really worth it.

]]>