From: rasmus at mindplay dot dk Operating system: linux/windows PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: Simple optimization to speed up many web apps
Description: ------------ I suspect the .= operator could be greatly optimized, using a very simple optimization. Reproduce code: --------------- $output .= "<div>".$string."</div>"; The answer to that probably is, PHP creates a copy of $output, and appends to that, e.g.: Expected result: ---------------- Just a simple string-concatenation. But many applications build HTML by appending to an output string in this manner - if you have 250KB of HTML in your $output variable already, every time you append to it, PHP needs to reallocate memory and copy 250KB of string data. Actual result: -------------- It works, but it's extremely inefficient (almost x 2 memory usage, plus huge overhead from copying the string every time) Since the .= operator was used, you could instead append directly to the string on the left side of the operator, after composing the resulting string on the right side of the operator. It seems what actually happens right now is this: $output = $output . "<div>".$string."</div>"; The difference is that the whole string, on the right side of the = operator, is composed, and then assigned. For the .= operator, this is unnecessary. >From my recent analysis of bottlenecks in Drupal (a poorly architected piece of software, I know, but popular nonetheless), it seems that a significant part of Drupal's slowness comes from the fact that everything it does involves appending to huge strings - often the entire output. I suspect that this optimization could potentially increase the speed of Drupal (and probably many other applications) dramatically. -- Edit bug report at http://bugs.php.net/?id=48044&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48044&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48044&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48044&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48044&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48044&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48044&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48044&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48044&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48044&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48044&r=support Expected behavior: http://bugs.php.net/fix.php?id=48044&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48044&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48044&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48044&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48044&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=48044&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48044&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48044&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48044&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48044&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48044&r=mysqlcfg
