At Confoo I had an interesting conversation with Guilherme Blanco regarding the fact that in Doctrine 2 they had a performance issue due to usage of array_key_exists() and how it was significantly slower than isset(). His anecdotal example was that doing isset() took 0.5 seconds, while array_key_exists() for the same operation took 5 seconds! That seemed wrong, given that array_key_exists() simply does a hash table look-up, to determine if the array key exists and the only speed difference would be due to the fact that isset() is a language construct and does not have the overhead of function & parameter processing. So, I've decided to do a quick benchmark using a 5,000 element array. [php] $arr = array(); $fp = fopen("/usr/share/dict/words", "r"); while ($i < 5000 && ($w = fgets($fp))) { $arr[trim($w)] = ++$i; } $s = microtime(1); for ($i = 0; $i < 100000; $i++) { isset($arr['abracadabra']); } $e = microtime(1); echo "Isset: ".($e - $s)."\n"; $s = microtime(1); for ($i = 0; $i < 100000; $i++) {...

My slides from the Confoo presentation on PHP 5.4 are up and can be viewed/downloaded from here: http://ilia.ws/files/confoo_php54.pdf I look forward to everyone's feedback either on this blog or via Joind.in. And in case you didn't know, PHP 5.4 was released yesterday! [Update March 3, 2012] Based on great suggestion from Rasmus, I've updated the charset slide to clarify that the change introduced in 5.4 relates to the default charset used by internal entities functions (htmlspecialchars, htmlentities, etc...) and updating the default_charset INI is one of the changes you may need to do to account for this change.

The slides from my "Introduction to PostgreSQL" talk at Confooare now available for view/download and can found here: http://ilia.ws/files/confoo_pgsql.pdf. Hopefully it will make people more interested in PostgreSQL, which is a great database system and take it into consideration when making their database platform decisions. For me personally, it was quite interesting, as it is one of the rare chances I get to speak about something that is not directly related to PHP, although I did sneak-in a few PHP specific slides ;-) I would very much appreciate feedback from all who had attended the talk and any suggestions on how to make it better are always welcome. Please send me your comments via this blog or via Joind.in. A big thanks for to Bruce Momjian from Enterprise DB who gave me some really good suggestions on improving the slides (already reflected in the PDF) and Christophe Pettus from PostgreSQL Experts, Inc. whose original PostgreSQL Intro talk had inspired mine.

While profiling our application I came across a a rather strange memory usage by the ob_start() function. We do use ob_start() quite a bit to defer output of data, which is a common thing in many applications. What was unusual is that 16 calls to ob_start() up chewing through almost 700kb of memory, given that the data being buffered rarely exceeds 1-2kb, this was quite unusual. I started looking at the C code of the ob_start() function and found this interesting bit of code inside php_start_ob_buffer() initial_size = 40*1024; block_size = 10*1024; Which directs PHP to pre-allocate 40kb of data for each ob_start() call and when this proves to be insufficient, increase by 10kb each time. Ouch! PHP does allow you to say how much memory ob_start() can use, via 2nd parameter to the function. However, if you exceed that size, PHP will promptly flush the captured data to screen, which means that unless you are really good at predicting your buffer sizes or vastly overestimate, there is a risk that...

My slides for my "Under the Hood" talk at ZendCon are now online and can be downloaded here. Thanks to all the attendees, especially those who left feedback at Joind.In.