Latest sites

  • 2017-11-26: New Drupal 8 site at Rue du Commerce, architected and tech-led by OSInet, just went throught Black Friday week with flying colors thanks to RabbitMQ
  • 2017-05-26: New headless Drupal 8 / Symfony 3 site at FranceTV Sport, architected and tech-led by OSInet, with RabbitMQ
  • 2017-02-20: New Drupal 8 site galaxy (+/- 70 sites) for Agences Régionales de Santé architected and tech-led by OSInet, delivered by Klee
  • 2015-08-21: 50% less server load with MongoDB on the Drupal 7 site factory at France Télévisions
  • 2015-07-15: Our first Drupal 8 production site at France Télévisions is live
  • 2014-08-18: 400% speedup in 3 weeks for : who said Drupal back-offices had to be slow ?
  • 2014-02-07: Sotchi Olympics traffic not a problem for , which I rearchitected on Drupal 7 in 2013
  • 2011-09-14: Completed migration of FranceInfo.FR from SPIP to Drupal
  • 2011-07-13: The new social network features of Le Figaro are now powered by an OSInet-designed MongoDB implementation

Quick news

  • 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
  • 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
  • 2013-10-18: My first commit went into MongoDB today. And, guess what ? It's in JavaScript
  • 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
  • 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
  • 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
  • 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ? Bets are on Later

Optimizing strings in PHP ?

Every so often, I get asked about whether it is really worth it to chase double quotes and constructs like print "foo $bar baz", and replace them with something like echo 'foo', $bar, 'baz', or even to remove all those big heredoc strings so convenient for large texts.

Of course, most of the time, spending hours to fine comb code in search of this will result in less of a speedup than rethinking just one SQL query, but the answer is still that, yes, in the infinitesimal scale, there is something to be gained. Even with string reformatting ? Yes, even that. But only if you are not using an optimizer.

Just don't take my word for it, Sara Golemon explained it years ago with her "How long is a piece of string" post, in 2006.

Note that her suggestion about apc.optimization is no longer relevant with APC 3.x, though, as this has been removed in APC 3.0.13, with optimizations now always on.

2011-02 UPDATE: as explained by TerryE in the comments, while this applied with older PHP versions (remember, this was written in 2006) which one still found live when reviewing older sites for upgrades, it does not apply to current versions of PHP 5.2.x and 5.3.x.

2010-04 UPDATE: the initial version of this post incorrectly mentioned phpdocs instead of heredocs. Thx dalin for pointing out the error. phpdoc-type comments DO come at a cost but that's when using the Reflection API, which actually interprets them to add information to ReflectionParameter instances, and this has nothing to do with string processing.

trackback link

I think you are confusing

I think you are confusing PHPdoc and heredoc. PHPdoc
* Converts baz into bar.
* @param $baz
*  The baz widget.
* @return
*  A newly minted bar.
function foo {

And heredoc:
= <<<EOD;
This is a long
-line string
that might contain a $variable
There is no cost to PHP comments. And as she mentions at the end of the article, if you are running an opcode cache that does optimizations (which you should be), like modern versions of APC, then there's no real difference between the different string styles. This is why there is no coder rule for string style. Choosing one style over another for the case of readability in that particular situation is far more important than the pico second that you will be saving.

phpdoc != heredoc

Ooopsie :-( Should always reread before saving posts. Thanks for pointing this out.

Please don't repeat "facts" that are no longer true

"Just don't take my word for it, Sara Golemon explained it years ago with her..."

Sarah wrote this is 2006. Have you check this claim with a reasonable current PHP version? I have with both 5.2 and 5.3. These observations simply no longer apply, so to repeat these claims misleads new PHP programmers trying to improve their style. For example, she gives a case which she quotes as generating 76 opcodes, but if you run it through VLD on a current version (in my case 5.3.3) this generates:

$ vld /tmp/zzz.php     # (I've wrapped the I/O)
filename:       /tmp/zzz.php
function name:  (null)
number of ops:  2
compiled vars:  none
line     # *  op                           fetch          ext  return  operands
  12     0  >   ECHO   '%0A%2B-----------------------------------------------------------%2B%0A%7C++++
  14     1    > RETURN

that is one opcode. These artefacts are a result of PHP code generation foibles that no longer occur. Using double quotes with embedded variables or heredoc syntax is now handled by current PHP code generators sensibly and has no material performance penalty.


Actually, around the time I posted this, I has to work reviewing an older site running PHP 4, on which this applied (I checked at the time). But you're right: I should have mentioned this was not true in later versions. I udpated the post accordingly, thank you for the note.