Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP Performance Benchmarks

maettig.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: PHP Performance Benchmarks

#31

Post by ihsw »

thejosh wrote: post #28
ihsw wrote: post #22

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+).

Depending on the ORM (or otherwise) it may have some level of caching, so the best performance would be using the PHP functions/classes directly (eg: PDO/MongoCollection/Redis).

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.

Re: PHP Performance Benchmarks

#32

Post by mfjordvald »

casualaistudent wrote: post #14

Does "ms" mean milliseconds or microseconds? And are these times for one iteration of the code fragment? 2 milliseconds to compare two strings seems awfully slow.

Definitely microseconds, most of my scripts with database interaction and all fully complete in around 50 milliseconds which would be impossible if string comparison took 2 milliseconds.

Re: PHP Performance Benchmarks

#33

Post by byroot »

mfjordvald wrote: post #32
casualaistudent wrote: post #14

Does "ms" mean milliseconds or microseconds? And are these times for one iteration of the code fragment? 2 milliseconds to compare two strings seems awfully slow.

Definitely microseconds, most of my scripts with database interaction and all fully complete in around 50 milliseconds which would be impossible if string comparison took 2 milliseconds.

When you do a benchmark you usually run the code more than once. It's milliseconds. The real question is how many time the code loop.

But anyway the interesting number is how many times it's slower compared to an equivalent code.

Re: PHP Performance Benchmarks

#34

Post by Firehed »

encoderer wrote: post #26
victorma wrote: post #6

Earlier quoted context omitted.

> 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.

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.

Re: PHP Performance Benchmarks

#35

Post by pippy »

Two things caught me by surprise:

    for ($i = 0; $i
I thought PHP would be smart enough to optimise this.

    'contains no dollar signs'
I practised the single vs. double quotes thing religiosity. I'm kind of embarrassed it doesn't actually make a difference.

Re: PHP Performance Benchmarks

#36

Post by pcwalton »

pippy wrote: post #35

Two things caught me by surprise: for ($i = 0; $i I thought PHP would be smart enough to optimise this. 'contains no dollar signs' I practised the single vs. double quotes thing religiosity. I'm kind of embarrassed it doesn't actually make a difference.

In general you can't hoist the length check out of the loop because of the possibility that the length might change during the loop. Proving that the length doesn't change during the loop is quite difficult; in general this requires alias analysis.

Re: PHP Performance Benchmarks

#37

Post by Confusion »

You can't trust benchmarks, unless you've either seen the code or trust the person posting the benchmark enough that he benched correctly. It's easy to benchmark something other than what you think you are benchmarking.

Re: PHP Performance Benchmarks

#38

Post by ludovicurbain »

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.

Re: PHP Performance Benchmarks

#39

Post by ludovicurbain »

ihsw wrote: post #24
victorma wrote: post #6

Earlier quoted context omitted.

> 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.

Database access latency will always trump any language design issues, except in extreme cases. This article does make some of those cases obvious, especially since they are easily-overlooked programming mistakes.

Database access latency will always be an important factor of _latency_ .

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.

Re: PHP Performance Benchmarks

#40

Post by icelancer »

pippy wrote: post #35

Two things caught me by surprise: for ($i = 0; $i I thought PHP would be smart enough to optimise this. 'contains no dollar signs' I practised the single vs. double quotes thing religiosity. I'm kind of embarrassed it doesn't actually make a difference.

"I thought PHP would be smart enough to optimise this."

How? This is not a trivial optimization for a compiler.

Post reply on HN