PHP Performance Benchmarks
maettig.com
maettig.com
http://www.slideshare.net/quipo/profile-your-php-application...
http://blip.tv/phpnw/phpnw10-lorenzo-alberton-profile-your-p...
My conclusion: Never use the ereg…() functions.
for ($i = 0; $i < count($users); $i++)
foreach($users as $user)Intuitively the for loop should be a lot fast as it isn't assigning anything each loop. Although in your example it may be slower because the count($users) would be ran on each iteration of the loop.
Foreach is doing an assignment in each iteration, robryan is right. But PHP variables are copy-on-write so $user is, until modified, just an entry in the symbol table which is very fast.
And that for() loop also has an assignment -- the incrementer.
Fix that:
for($i = 0; $count = count($elements); $i < $count; $i++) { }While fun to look at and calculate, it also doesn't mean a lot for most applications. I would argue that data fetching from DBs or caches will be the majority of execution time.
People keep saying that, and I would like to see some numbers for that also.
The DB dataset could be already cached in memory, for example.
That doesn't prevent anyone from coding stuff that requires 20 times less application servers while using the same amount of database (+caching) servers.
The very idea that because the DB call takes a while to complete, we can waste even more CPU cycles is a complete misunderstanding of real world use cases.
But then, the very use of PHP means that you don't give a shit about execution time or server costs at all.
But that pales in comparison to the overhead of a Database call, or even a call to Redis or Memcached.
I've read (from sources I trust) that a database call on a modern stack like .Net or JVM is 4 orders of magnitude slower than a local method call. Think about that. So if the time you spend brushing your teeth is a local method call, the entire next day is a database query.
I can't remember the source here but the information is available with a few minutes of coding or googling.
And to the caching point -- having data cached locally in memory is great, but you can't trust that.
You can if you design around handling a possibly-stale cache.
Are you disputing the premise or just disagreeing for the sake of it?
for ($i = 0; $i < count($array); $i++)
'contains no dollar signs'
How? This is not a trivial optimization for a compiler.
This is purely anecdotal but I use PHP for large scripts doing lots of inserts/deletes (>100,000) from databases and relatively simple logic.
In addition to the above, PHP extensions would be extremely preferable to pure-PHP libraries for database interaction simply because the extensions will be written in C and lack the overhead of the language.
You're using outdated APC code. Update to the latest, it resolves issues with the 5.4 line. We use it in production, zero issues.
2 milliseconds to compare two strings seems awfully slow.
But anyway the interesting number is how many times it's slower compared to an equivalent code.
My conclusion: count() is horribly slow. Always precalculate it, if possible.
In PHP they actually check the length of an array at every invocation of count(). As far as I can see the numeric value for length isn't stored anywhere.
It's not count() that's benchmarked here, its the difference between "$a < $b" and "$a < function_call($b)".
That's just a guess, though, having not actually looked at the code myself.
Also, foreach(range(1, 1000 * 1000) as $i) will execute at roughly the same speed as for($i = 0, $count = 1000 * 1000; $i < $count; $i++), so the difference is negligible.
Numeric arrays in PHP are AS SLOW as associative array, that's pure fail and one of the reasons PHP::fannkuch is so slow.