Following a talk at PHPLondon on the SPL library last month I decided to play about with SPL. I was curious as to the difference in speed between SplFixedArray and a normal array particularly when it came to reading from the array.
So I initialized an array of 100,000 elements – I then timed how long it took to access each element in the array, in order. I did this 100 times and took the amount of memory used (as recorded by memory_get_peak_usage) and the total time taken. The benchmarks were done on PHP 5.3 RC2 under Linux (Kernel 2.6) on a Intel Core 2 Duo 1.83Ghz.
The following were my compile options
CXXFLAGS=”-O3 -fomit-frame-pointer” ‘./configure’ ‘–enable-zip’ ‘–with-mysql=mysqlnd’ ‘–enable-sockets’ ‘–with-mm’ ‘–with-gd’ ‘–with-gmp’ ‘–with-jpeg-dir’ ‘–with-png-dir’ ‘–with-mcrypt’ ‘–with-curl’ ‘–with-openssl’ ‘–with-freetype-dir’ ‘–enable-calendar’ ‘–enable-mbstring’ ‘–enable-exif’ ‘–enable-ftp’ ‘–prefix=/opt/php’ ‘–with-zlib’ ‘–with-bz2′
And now for the results which are quite surprising
CPU time in seconds - SPL vs Normal PHP array
| Memory KB | Time Taken (sec) | |||
| SPL | Non-SPL | SPL | Non-SPL | |
| Reading using [] | 31570 | 74729 | 25.28 | 25.49 |
| Reading using iterator | 32000 | 75008 | 19.77 | 13.85 |
| Writing | 36096 | 75008 | 39.60 | 55.17 |
| count() | 32000 | 75008 | 52.37 | 47.45 |
| sizeof() | 32000 | 75008 | 51.25 | 47.21 |
So it appears that SPL array is faster than a standard array – by about 0.9% for reads. The SplFixedArray also uses 1/2 the memory of a standard PHP array which is a handy memory saving. SPL fixed arrays are much quicker to write to compared to standard arrays by about 39%
Both the sizeof and count functions are slower with SPL. However if you have set the size of the array (as you must with a SplFixedArray) then you shouldn’t need to use these. Surprisingly using the iterator is also slower but overall SPL does seem a lot more memory efficient.
So it would seem that SplFixedArrays aren’t good for everything. It’s all swings and roundabouts and you lose flexability in order to gain speed on certain operators. So don’t go replacing all of your arrays with SPL but it’s worth remembering that they are there should you need them.
Cool, interesting stuff! I wonder how your experiments will compare to http://developer.studivz.net/2009/03/18/php-spl-data-structures-benchmark/ .
do you happen to have the code available that you used in this benchmark? want to do an apples to apples comparison and maybe some server tuning and this seems to be a good bench to base off of.
Thanks!!!
I’ve got the code on my laptop (which is at home at the moment) – I’ll upload the code in about 12 hours or so – not sure how useful it will be to use for server tuning as it doesn’t test things like disk IO but let me know how you get on
Update: Just had a thought, if you wanted to get a better idea of how PHP performed on your server you could try timing the PHP test cases “make test” and seeing how long they take? this might give you a better over all view than using my benchmarks for SPLFixedArray (unless you just want to test SPLFixedArray)
It’s SplFixedArray not SPLFixedArray.
It’s also “lose”, not “loose”.
And “it’s”.
Spelling mistakes corrected, thanks for pointing them out – spelling isnt my forté as you can probably tell.. http://xkcd.com/326/
The reason for the surprising lack of performance improvement is that SplFixedArray doesn’t implement a real C-like array underneath, it’s still an associative array driven by a hash table just like Array(), *effectively nullifying any performance gains*, though as you mentioned, memory footprint is lower. It remains unexplained why the authors of the SPL chose such a pointless, no-gain implementation. I’m hoping that they address this in a future release.
That is confusing indeed.
I think they wanted to create api so that people could start using it and at some stage actually implement it on static c array to gain a lot in performance.
I cant believe they did not even hardwire count call?! i mean that one should be a constant should it not? and then return would take almost no time.
any way i like the idea so i dont want to complain too much but it should have a better implementation thats true. what is the point of me using the new api if there is no performance improvement at all?
Art