Comments for Matt Knight

Comment on Node.js vs PHP Performance – Maths by Nick

Nick — Fri, 27 Jan 2012 19:29:31 +0000

Iam very interested in node for embedded systems and industrial automation use.
I changed the code and on my machine for 1,000,000 iterations it went from 2 ms to 3 ms or 4ms , which seems to suggest that it is doing the maths! its very fast anyway.
when I made the variables global the time increased to 13 ms, which I think is reasonable.

Actually I connected this maths function to a 1 sec timer and in the same test software I am running a simple browser app and one hardly notices the additional over head.

This rather confirms my wildest dreams that we can use a server side script to compute process control set points and then pick them up by a simple httpget from a client sensor or actuator.

Definitely food for thought and worthy of a lot more testing.

Comment on Node.js vs PHP Performance – Maths by Fabian

Fabian — Wed, 11 Jan 2012 15:59:46 +0000

Iuc, that is probably right, but I suspect that the PHP interpreter will do the same. Also your changes wont change anything, any compiler doing pre-calculation will still do those calculations first.

To the author: “You’ll notice that in each case I have instantiated the variables outside of the for loop”. Actually you haven’t instantiated anything there. You only _declared_ them.

Comment on Node.js vs PHP Performance – Maths by luc R

luc R — Sun, 14 Aug 2011 02:26:20 +0000

I think you should retest differently.

Instead of
a = 1234 + 5678 + i;
b = 1234 * 5678 + i;
c = 1234 / 2 + i;

can you try :
a = 1234 + i + 5678;
b = 1234 + i * 5678 ;
c = 1234 + i / 2 ;

I suspect that the JS optimizer is not doing the full math and it’s doing pre-calculation like any C compiler.
When it converts the program into byte code it probably do the calculation there. Leaving only a=6912+i

Comment on Optimising Zend_Config by Matt

Matt — Mon, 18 Jul 2011 18:28:33 +0000

Just to address some of the comments above about caching….

I completely agree that caching is essential. No site with any significant traffic should run without config caching – as I mentioned at the end of the first section in the article. However, this doesn’t address the issue of the uncached (assuming no pre-warming) experience.

The situation I was talking about was two-fold – firstly how to parse the INI files more efficiently, and secondly why using an array (or ArrayObject) is better than a Zend_Config object.

It’s a very valid point that Zend is aimed at PHP 5.2 or greater, hence why I wrote this as an article discussing an alternative to Zend_Config_Ini, and not submitting it as a patch. There are many users of Zend_Framework 1.x out there, using PHP 5.3, for whom this could significantly improve the performance of their application.

Comment on Optimising Zend_Config by Johannes

Johannes — Mon, 18 Jul 2011 10:25:38 +0000

You are so completely right

When we discovered the performance implications of Zend_Config (thanks to XHProf), we decided to use Zend_Config only to generate a config cache. The cache generator uses Zend_config to read the INIs and generate native PHP arrays

Comment on Optimising Zend_Config by Artem

Artem — Sun, 10 Jul 2011 00:14:27 +0000

Matt, you should be caching the results of Zend_Config on production. This is what every sane person should be doing for high traffic volume web apps. Large software project shouldn’t be building configuration data at runtime on every request. It should be stored away in memory.

The subtle attack on Zend Framework in terms of performance is unnecessary and, frankly, cheapens the tone of this discussion. Remember that Zend Framework requires PHP 5.2 or greater and the majority of the team is spending most of their time working on Zend Framework 2 at the moment.

Comment on Optimising Zend_Config by Anton

Anton — Thu, 07 Jul 2011 18:43:26 +0000

Caching the config instead of reimplementing the config class is quicker, easier and results in a nice speed increase. See how I have done it, http://www.hellotecho.com/cache-your-zend-framework-config-to-improve-performance.

Comment on Optimising Zend_Config by Mike Willbanks

Mike Willbanks — Thu, 07 Jul 2011 18:23:24 +0000

I can definitely see why you are looking at it this way – we do cache our configuration which actually helps out greatly and essentially removes many of the complexities that you see here. A cached copy is always a faster copy. We keep anything from a configuration file inside of the shared memory to ensure the speed.

Comment on Optimising Zend_Config by Dennis Becker

Dennis Becker — Thu, 07 Jul 2011 15:50:21 +0000

Can you add a download link for your patched Zend_Config version? It would be easier to try your changes within an application

Comment on Optimising Zend_Config by Hans-Peter Buniat

Hans-Peter Buniat — Thu, 07 Jul 2011 10:14:32 +0000

This breaks some compatibility/features of Zend_Config, as its just not parse_ini_file()/parse_ini_string().

You could gain the same performance boost by using an opcode-cache (e.g. XCache) for the parsed Zend_Config object. This keeps support for sections, etc and with minor additions you may even get a extendable Config-Object which supports multiple config-files, optionally with sections and super fast Config-Creation, as there is in fact no Zend_Config execution needed, when you’re creating you’re cache-object as a deployment-target.