Trival PHP string concatenation benchmarks, proving time better spent elsewhere.

Trival PHP string concatenation benchmarks, proving time better spent elsewhere.(github.com)

8 points by magnetikonline 12 years ago | 6 comments

AaronFriel 12 years ago |

This benchmark measures the time to generate random characters - per Mithaldu's remark - not the time to shuffle bytes around. If it actually took around 7 seconds to shuffle about 20 megabytes[1] of data around, no one would use PHP for anything. Of course, the algorithm actually performs 20 million string concatenations, because of the way random strings are generated.

To give you an idea of how slow that is, maximum memory throughput with memcpy on many modern systems is measured in the tens of gigabytes per second. The comparison to .NET at the end is amusing, because the same benchmark including the random generation of characters can be done many times faster in C#. And I'm not even good at writing C#, having spent most of my time in Haskell. But I did it anyway.

    PHP version (in C#)         = 1.8660s

    Using prebuilt array        = 0.0654s

    Using StringBuilder, random = 1.5628s

    Using StringBuilder, array  = 0.0749s

EDIT: If I construct the StringBuilder with a size parameter, it shaves another 0.02 seconds off (or 25% of execution time).

Gist for source: https://gist.github.com/AaronFriel/9699764

The original should be rewritten to not be a test of PRNG throughput. In the amount of time that it took PHP to generate those random strings, my unoptimized, first-try C# concatenates about a hundred times faster.

[1]I am aware that this is merely the size of the resultant string - 20 characters times 1,000,000 iterations. But it's within a factor of two of the total bytes copied, and I don't know PHP's internal string representation. I don't know if each append alters an entire string, rewrites a rope structure, etc. In all likelihood, many fewer than 20 million bytes were harmed by PHP in the making of this benchmark.

Mithaldu 12 years ago |

Sans per-call profiling i'd expect the string concatenation time to be dwarved by the calls to rand.

Edit: Does PHP even have any per-call profilers?

magnetikonline 12 years ago | |

For sure - it totally dwarves it. I'm not so worried about the time value itself, just which method is "faster".

krapp 12 years ago |

That is interesting...I would have assumed concatenating arrays was slower anyway.

Would it be relevant to test this using file reads?

magnetikonline 12 years ago | |

Yeah, as I note in the docs it's pretty Trival and a quick 10 minute hack around :) Don't take it all too serious. But the last point about .NET and StringBuilder() used to hang around in my head during the dark days of my early ASP.NET development.

Not sure about the file reads, defeating string interning seemed to be the point that helped show any really difference. Quite an interesting/cool topic that.

AaronFriel 12 years ago | | |

Unless PHP has truly awful string concatenation performance, your microbenchmark will spend almost all of its time generating pseudorandom numbers, and a tiny fraction of its time moving bytes around to concatenate strings.