Gonzalo Ayuso has a new post to his blog today looking at the performance of PHP exceptions and how it could effect your application's overall speed.

Sometimes we use exceptions to manage the flow of our scripts. I imagine that the use of exceptions must have a performance lack. Because of that I will perform a small benchmark to test the performance of one simple script throwing exceptions and without them.

His (little) benchmarking scripts are included - both looping 100000 times, one throwing an exception and the other not. The results were pretty obvious - the memory usage was about the same but the speed was about ten times faster without the exceptions (in PHP 5.3). In PHP 5.4, however, the numbers were closer as far as time to run. Obviously, unless you make super heavy use of exceptions, you're not even going to come close to something like this (micro-optimization anyone?).

In a new post to his blog, Bence Eros takes a look at the request execution path that your Kohana-based application goes through each time a page request is made.

Yesterday Kohana 3.1 RC1 has been announced and tagged. I think now it's time to get familiar it. In this post I'm going to examine the refactored request execution workflow. Let's start with the bootstrap mechanism.

He notes that most of the changes don't happen at the boostrap level. They're more behind the scenes than that, with changes in how it works within the HMVC design pattern. He talks about the changes in the Request objetct's constructor, factory and client methods. He also includes a full flow of a request for a sample welcome controller, describing the steps it falls into and a list of classes that the Request object may have used.

Adam Pullen has posted a three-part series of articles looking at execution filters in Symfony to modify/handle the request differently than just the normal GET or POST would pass through.

Symfony is a powerful PHP Framework. One of the features that I have really taken advantage in my last project is request filtering or execution filtering. Request filters allow you to inspect the request before and after the main logic is executed. Why would one want to do this? There are many reasons to implement request filtering.

Here's his three articles:

• Execution Filters
• Execution Filters:Add objects to global environment
• Execution Filters: Controlling output

You can find out more on their practical use in this section of the Symfony site.

New on his blog today Sameer Borate has a post looking at his method for making parallel connections with curl based on this library from Pete Wardens.

Most people use the 'easy' mode - in this mode when we issue multiple requests, the second request will not start until the first one is complete. This is known as synchronous execution, and this is the one we normally use. [...] In [multi] mode all requests can be handled in parallel or asynchronously. And it can be quite handy and time saving on many occasions.

He gives some code examples of how to use the library to simplify the curl connections and requests and pass the result off to a callback when it's done. His more practical example shows how to search for a set of terms on Google and return the results for output.

In a new post to his blog Giorgio Sironi has a (more balanced) comparison of Java versus PHP that them on topics like how they handle typing and their execution models.

If you exclude C and its child C++, the most popular programming languages in the world are Java and PHP, which power most of the dynamic web. I have working experience with PHP and for academical purposes I am deepening my knowledge of Java, thus I'd like to point out similarities and key differences between these two languages. Every language has its pros and cons, so there's no absolute winner here.

He briefly covers their history, java's static versus PHP's dynamic typing, how they both handle objects, their execution plans and how easy they are to deploy when it comes to general applications.

PHPBuilder.com has a new article from Jason Gilmore on security in command-line applications posted today and what you can do to help protect your scripts from unwanted system command access.

In this tutorial, I'll show you how to securely execute a variety of system-based commands via a PHP script, demonstrating how to build web applications that can tightly integrate with both the operating system and third-party software.

He mentions the proper filtering of input strings (user input), how it can protect your and your application as well as a few examples of using the PHP execution functions (like exec or passthru) and how to apply the shell escaping commands (like escapeshellarg) as a first layer of security.

Debugging resources being used by your script has always been a pain, and many developers have come up with their own libraries to handle the process. Ryan Campbell has his own entry in the category - the PHP Quick Profiler.

In our company, code reviews play an integral part in the development process for making quality software. We opt for a mentor style approach with Wufoo, where a developer works on a segment for a period of time and then passes it up to a more experienced developer for review.

[...] To reduce this repetition of checking the same requirements over and over], we invested some time creating something we've called the PHP Quick Profiler-we call it PQP for short. It's a small tool (think Firebug for PHP) to provide profiling and debugging related information to developers without needing them to add a lot of programmatic overhead to their code.

The post gives several screenshots of the tool in action and code to get you up and running quickly. The Profiler can keep track of memory usage, "runaway" includes, execution time and database activity. There's also an online demo so you can try it out yourself.

Here's the link to the latest version's download.

Brian Moon had a problem - one of his cron jobs was lasting for much longer (hours!) than it should have been. He tweaked, tested and debugged the script and finally came down to a call to in_array, something he comments on as being "quite slow".

See, this job is importing data from a huge XML file into MySQL. After it is done, we want to compare the data we just added/updated to the data in the table so we can deactivate any data we did not update. [...] We then compared the two arrays by looping one array and using in_array() to check if the value was in the second array. [...] So, that was running for hours with about 400k items. Our data did not contain the value as the key, but it could as the value was unique.

He method, replacing the in_array call that had to do a full array scan for each time through the loop with an isset/unset combo on the unique key, changed the execution time down from about 4 hours to 0.8 seconds.

Nessa has set up a post in an effort to help budding PHP developers out there with some of the most common problems they might come across in their work and how to handle them a bit more gracefully with error handling:

I'm going back to the basics here, you know, when you wrote your first PHP script and saw an ugly-ass error message pop up on your screen? Error messages are the best tool a programmer has.

She talks about how to set up the error reporting first, making sure that you're getting things up and useful. From there she describes some of the common errors that you might see including:

• Parse errors
• MySQL Result source errors
• Stream errors
• Max Execution Time errors

Check out the rest of the post for more types.

On the PHP Discovery blog, there's a new post reminding PHP developers of some of the more dangerous ways that remote execution could effect your site and some of the common entry points it can have.

PHP has numerous ways to execute raw PHP code unless you the programmer stops it. Best way in preventing these methods is making sure you check the input of what your users are inputting, and making sure you escape all malicious actions that a hacker,cracker, kiddy scripter might want to do to your website.

He summarizes four of the things from the Pro PHP Security book from Apress (by Chris Snyder and Michael Southwell) that can leave holes in you application for would-be explots - preg_replace, shell_exec/exec, eval (which we all know is only one letter from "evil" anyway) and require/include.