As with all programming languages, in PHP there are always several ways to do something. As with most, there are differences in performance depending on how something is done – usually as a trade-off for code neatness. Take for example, running through an array.

$key = array_keys($aHash);
$size = sizeOf($key);
for ($i=0; $i<$size; $i++) $aHash[$key[$i]] .= "a";

Not particularly neat, but by far the fastest way to do the job. If we start to reduce the amount of code, we can find ourselves with this:

while(list($key) = each($aHash)) $aHash[$key] .= "a";

Although neater, the problem we’ve generated here is that for each time the loop runs, we’re relying on return values from the list() and each() functions. Our previous loop ran these at the start. Test have shown this method to be over 200% slower that our first version.

If we take this further, and use the notoriously inefficient foreach() function for our loop, we could be up to 600% slower than our original.

foreach($aHash as $key=>$val) $aHash[$key] .= "a";

So if the problem stems from the inclusion of unnecessary functions inside loops, the extent of it is linked to how long it takes those functions to execute. Comparing the two lines of code, one with the length of the array pre-calculated:

$size = count($array);
for ($i=0; $i<$size; $i++) {

and the other with an inline function:

for($i = 0; $i < count($array); $i++) {

It may surprise you to know that most tests put the latter at around five hundred times slower the former, and that's just using a simple count() function.

For more information on the various benchmarks mentioned within this post and others, see PHP Bench.

Mac OS X has some fantastic screenshot capabilities built into it, but there is one annoyance that doesn’t seem particularly well thought through – putting all the screenshots on the Desktop. This can be changed through the use of the “defaults” command in the Terminal. Here’s a decent setup for it:

Open your home folder, then “Pictures” and create a folder called “Screenshots”. Open up Terminal and issue the following command:

defaults write com.apple.screencapture location /Users/YourUsername/Pictures/Screenshots

If you’re a Leopard user, do what I do and drag this screenshots folder into the stacks area of your dock then Ctrl-Click the stack and select “Grid” from the “View content as”. You will now be able to see all of the screenshots you’ve made recently by clicking the stack. If you’re using Tiger, you can do the same and then Ctrl-Click to see what’s in the folder.

Although there are multitude of browsers out there, sense does prevail (sort of) in that they are all based on handful on rendering engines. This is the important part of a Web browser that actually deals with the layout of the HTML and CSS – many browser will share a rendering engine and then add their own menus, toolbars etc around it. Here’s a quick run-down of the rendering engines and which browsers they are used in.

Gecko – an open-source and highly standards-compliant rendering engine used in Firefox and it’s derivatives Camino and Seamonkey, as well Epiphany.

Trident – the one that causes all the problem. Microsoft’s rendering engine sits behind Internet Explorer but also forms the basis for Microsoft’s ActiveX wbe controls. This means it also finds its way into various applications such as AOL Explorer, Real Player, MSN and the Yahoo! Browser.

KHTML – an open-source component developed by the KDE team (a Linux desktop environment). It is only really used by KDE’s file / Web browser Konqueror, although it is very standards compliant and very similar to WebKit in it’s rendering, so does not present many problems in cross-browser testing. KHTML was actually the first rendering engine to pass the Acid2 test.

WebKit – originally forked from KHTML by Apple in order to bring it to the OS X platform, it ended up not being able to stay in-sync with KHTML and is now considered a separate engine. It was re-open-sourced in 2005 and is currently in use in Apple’s Safari (all platforms), Google Chrome, Shhira, Omniweb, iCab and Epiphany.

Presto – the Presto engine is developed by Opera and used solely by the Opera Browser. However, derivatives of the Opera browser are starting to be used in lots of home devices such as the Nintendo Wii and DS.

Probably the biggest change in CSS3 are optional changes to the box-model and how browsers render heights and widths. Using the traditional box-model, heights and widths of boxes set the dimensions of the internal content area. Any padding, borders or margins added to that box increase the width beyond what has been specifically declared.

This will still be the default – setting the “box-sizing: ” attribute to “content-box”. However, set the “box-sizing: ” attribute to “border-box ” and all borders and padding will be subtracted from the declared heights and widths when rendering.

Support is already available for this in Opera using the “box-sizing: ” attribute. Firefox and Safari support this as well, but using the respective experimental prefixes, “-moz-box-sizing: ” and “-webkit-box-sizing: “.

Many people complain about Safari rendering text as bold, even when the “font-weight: ” property is set to “normal”. The truth is you can fiddle with the sizes and font-weights forever to no avail. What’s causing the problem is the as-yet-not-standard “text-shadow: ” property.

Part of the upcoming CSS3 specification, the “text-shadow: ” property is used for creating a drop-shadow on your text. Safari has supported this property since Version 1.0 and uses it by default to provide a quasi anti-aliasing effect on the text. So, in order to get Safari’s text to render without it, and therefore more similarly to the other browsers, add the following to the CSS declaration:

text-shadow: 0px 0px;