41–49 of 49 posts
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.
My conclusion: count() is horribly slow. Always precalculate it, if possible. https://github.com/php/php-src/blob/master/ext/standard/arra... 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)".
Earlier quoted context omitted.
The difference between php-5.2 (the version used), php-5.3, and php-5.4 is quite vast for each version, especially since php-5.4 basically cut memory usage/execution time by a third at worst (or directly by half at best) when compared to php-5.3. This is purely anecdotal but I use PHP for large scripts doing lots of inserts/deletes (>100,000) from databases and relatively simple logic.
Nice, I'll have to give 5.4 a try. Currently using 5.3, and finding it memory hogging when doing a lot of database operations in a row (300k+).
Earlier quoted context omitted.
Nice, I'll have to give 5.4 a try. Currently using 5.3, and finding it memory hogging when doing a lot of database operations in a row (300k+).
Sadly, PHP 5.4 stills fails badly with APC in several cases, so I do not consider it ready for production yet
Earlier quoted context omitted.
You're re-calculating the count() on each iteration. Of course it's slower. Fix that: for($i = 0; $count = count($elements); $i
Yeah I know, done purposefully to see how MUCH slower this is. This is how the majority of code is written in the wild, rarely do you see the `count()` pulled outside of the `for()`.
Two wrong conclusions: === is infinitely better than empty() due to less glitchy behavior. don't use empty, ever. Numeric arrays in PHP are AS SLOW as associative array, that's pure fail and one of the reasons PHP::fannkuch is so slow.
Earlier quoted context omitted.
Nice, I'll have to give 5.4 a try. Currently using 5.3, and finding it memory hogging when doing a lot of database operations in a row (300k+).
Sadly, PHP 5.4 stills fails badly with APC in several cases, so I do not consider it ready for production yet
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.
Earlier quoted context omitted.
Large web apps do often spend a lot of time manipulating strings and arrays in memory. It's absolutely true and I've seen it myself several times -- a performance penalty that is measurable and noticeable to users. 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 o…
> 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?
Earlier quoted context omitted.
> 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.
Not really. There is no system that ever has had an always-fresh cache. Are you disputing the premise or just disagreeing for the sake of it?