<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Professional PHP &#187; performance-optimization</title>
	<atom:link href="http://www.procata.com/blog/archives/tag/performance-optimization/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.procata.com/blog</link>
	<description>PHP Programming, Web Development, PHP Advocacy and PHP Best Practices.</description>
	<lastBuildDate>Tue, 20 Oct 2009 00:57:46 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Benchmarking PHP&#8217;s Magic Methods</title>
		<link>http://www.procata.com/blog/archives/2007/11/04/benchmarking-phps-magic-methods/</link>
		<comments>http://www.procata.com/blog/archives/2007/11/04/benchmarking-phps-magic-methods/#comments</comments>
		<pubDate>Mon, 05 Nov 2007 00:01:02 +0000</pubDate>
		<dc:creator>Jeff</dc:creator>
				<category><![CDATA[PHP]]></category>
		<category><![CDATA[Software Design]]></category>
		<category><![CDATA[benchmarks]]></category>
		<category><![CDATA[performance-optimization]]></category>
		<category><![CDATA[profiling]]></category>

		<guid isPermaLink="false">http://www.procata.com/blog/archives/2007/11/04/benchmarking-phps-magic-methods/</guid>
		<description><![CDATA[Larry Garfield has an interesting set of benchmarks covering many of PHP&#8217;s magic methods.  His results correspond pretty well to my own benchmarks in the area.  The thing to take away is that its not necessarily the overhead of the magic methods, but rather what you do inside them.  Its hard to [...]]]></description>
			<content:encoded><![CDATA[<p>Larry Garfield has an interesting <a href="http://www.garfieldtech.com/blog/magic-benchmarks">set of benchmarks</a> covering many of PHP&#8217;s <a href="http://php.net/oop5.magic">magic methods</a>.  His results correspond pretty well to my own benchmarks in the area.  The thing to take away is that its not necessarily the overhead of the magic methods, but rather what you do inside them.  Its hard to do anything useful inside a magic method, such as __get or __call that isn&#8217;t <b>10 to 20 times slower</b> than the &#8220;non-magic&#8221; solution.</p>
<p>There are probably more than a few naive programmers who would read results like this and start to avoid these constructs in their own code for performance reasons.  These are the same kinds of people obsessing over a few single or double quotes, who eschew &#8220;slow&#8221; objects in favor of switch statements that are many times slower than the polymorphic method calls they are trying to avoid.</p>
<p>But, that&#8217;s not the end of the story.  Larry ran his benchmarks using 2,000,000 iterations.  The <b>N</b> really matters here.  Sure, iterators are slower than arrays, but you aren&#8217;t going to be iterating over two million things.  I tend to fetch my database records in lots of 25 or 50.  You aren&#8217;t going to be making two million invocations of __call.  But how many will you make?  Under what value of N does the performance of these techniques cease to matter?  Is it ten, one hundred, one thousand, or ten thousand?  You may be surprised at how few calls your program actually does and how little impact it has on performance.</p>
<p>As <a href="http://netevil.org/">Wez</a> and <a href="http://www.travisswicegood.com/">Travis</a> point out in their comments, profiling is the way to find out the potential impact and to discover your true N.</p>
<p>Paul M. Jones has a <a href="http://paul-m-jones.com/blog/?p=182">good example</a> of what I&#8217;m talking about.  There, call_user_func_array appears to be a bottleneck, but it turns out that its the function being called, htmlspecialchars, not the calling process that consumes the balance of the time.  In that case, the function was &#8220;only&#8221; called 300 times.  I find that order of magnitude to be fairly typical.  Something to be aware of, perhaps, but not something to obsess over.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.procata.com/blog/archives/2007/11/04/benchmarking-phps-magic-methods/feed/</wfw:commentRss>
		<slash:comments>19</slash:comments>
		</item>
		<item>
		<title>Faster Page Loading</title>
		<link>http://www.procata.com/blog/archives/2006/10/31/faster-page-loading/</link>
		<comments>http://www.procata.com/blog/archives/2006/10/31/faster-page-loading/#comments</comments>
		<pubDate>Tue, 31 Oct 2006 22:31:56 +0000</pubDate>
		<dc:creator>Jeff</dc:creator>
				<category><![CDATA[PHP]]></category>
		<category><![CDATA[Web Design]]></category>
		<category><![CDATA[ajax]]></category>
		<category><![CDATA[caching]]></category>
		<category><![CDATA[firefox]]></category>
		<category><![CDATA[javascript]]></category>
		<category><![CDATA[page-loading-performance]]></category>
		<category><![CDATA[performance-optimization]]></category>
		<category><![CDATA[safari]]></category>
		<category><![CDATA[tamper-data]]></category>

		<guid isPermaLink="false">http://www.procata.com/blog/archives/2006/10/31/faster-page-loading/</guid>
		<description><![CDATA[Google engineer Aaron Hopkins wrote a good article on page loading times  (via Harry).  He talks about the impact of AJAX on page load times, focusing on connection limits,  latency and the large number of external objects on your typical AJAX page.  He offers a variety of tips on improving page [...]]]></description>
			<content:encoded><![CDATA[<p>Google engineer Aaron Hopkins wrote a good article on <a href="http://www.die.net/musings/page_load_time/">page loading times</a>  (via <a href="http://www.sitepoint.com/blogs/2006/10/30/the-case-for-registering-multiple-domains/">Harry</a>).  He talks about the impact of AJAX on page load times, focusing on connection limits,  latency and the large number of external objects on your typical AJAX page.  He offers a variety of tips on improving page load times, including doing more with the connections you have, busting the connection limit, caching, and sending less data.</p>
<p>I wrote about <a href="http://www.procata.com/blog/archives/2004/05/17/web-page-loading-performance/">web page loading performance</a> a while ago, when I linked to Dave Hyatt&#8217;s most excellent explanation of the issues involved with <a href="http://weblogs.mozillazine.org/hyatt/archives/2004_05.html#005496">testing page load speed</a>.  In fact the Safari browser blog endorses Aaron Hopkins article and mentions how to <a href="http://webkit.org/blog/?p=75">measure page loading times</a> in Safari using the debug menu.</p>
<p>On the Mozillia front, the <a href="http://tamperdata.mozdev.org/">Tamper Data</a> extension generates some amazing graphs of when elements on a page load and how long it takes.</p>
<p>On the topic of sending less data, the Yahoo! User Interface Blog weighs in on <a href="http://yuiblog.com/blog/2006/10/16/pageweight-yui0114/">page waits</a> with a discussion of javascript minimization versus compression.  They also briefly cover the YUI decision to serve components a la carte, rather than in an aggregated file.</p>
<p>Cal Henderson of Flickr also takes up this topic in <a href="http://www.thinkvitamin.com/features/webapps/serving-javascript-fast">serving JavaScript fast</a>.  He goes into more depth about the issue of a la carte external objects versus aggregated external objects as well as covering compression and caching issues with examples in PHP.</p>
<p>From the PHP perspective, <a href="http://public.yahoo.com/~radwin/talks/yapache-oscon2006.htm">Michael J. Radwin</a> and <a href="http://www.niallkennedy.com/blog/archives/2006/07/rasmus-lerdorf-php-web20.html">Rasmus Lerdorf</a> have covered web application performance issues in conference talks.</p>
<p>Are <a href="http://www.web-caching.com/cacheability.html">your web pages cacheable</a> or <a href="http://public.yahoo.com/~radwin/talks/http-caching-apachecon2005.htm">not</a>?</p>
<p>On the home front, this is my first post on this blog since I&#8217;ve installed <a href="http://mnm.uib.es/gallir/wp-cache-2/">wp-cache2</a> and upgraded to <a href="http://eaccelerator.net/">eAccelerator 0.9.5</a>.  And my first post since my fishing vacation, too <img src='http://www.procata.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
			<wfw:commentRss>http://www.procata.com/blog/archives/2006/10/31/faster-page-loading/feed/</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
		<item>
		<title>A Glimpse into the Future: PHP 6</title>
		<link>http://www.procata.com/blog/archives/2005/11/22/a-glimpse-into-the-future-php-6/</link>
		<comments>http://www.procata.com/blog/archives/2005/11/22/a-glimpse-into-the-future-php-6/#comments</comments>
		<pubDate>Tue, 22 Nov 2005 20:40:09 +0000</pubDate>
		<dc:creator>Jeff</dc:creator>
				<category><![CDATA[PHP]]></category>
		<category><![CDATA[benchmarks]]></category>
		<category><![CDATA[performance-optimization]]></category>
		<category><![CDATA[php-5]]></category>
		<category><![CDATA[php-6]]></category>
		<category><![CDATA[unicode]]></category>

		<guid isPermaLink="false">http://www.procata.com/blog/?p=158</guid>
		<description><![CDATA[Derick Rethans has posted the notes from the recent PHP 6 meeting in Paris.  All I can say is wow!  PHP has a bright future.  Good job guys.
I&#8217;ve also been impressed with the new upgrade notes for 5.1.  Good job there, too.
I&#8217;ve read over the whole thing and I like what [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.derickrethans.nl/">Derick Rethans</a> has posted the <a href="http://www.php.net/~derick/meeting-notes.html">notes from the recent PHP 6 meeting</a> in Paris.  All I can say is wow!  PHP has a bright future.  Good job guys.</p>
<p>I&#8217;ve also been impressed with the new upgrade notes for 5.1.  Good job there, too.</p>
<p>I&#8217;ve read over the whole thing and I like what I see.  One thing did jump out at me.</p>
<blockquote><p>
We also discussed whether we should even allow Unicode mode to be turned off as current micro benchmarks show that the Unicode implementations of some of the string functions are up to 300% slower, and whole applications up to 25% slower. Disallowing Unicode mode to be turned off is expected to slow down the adoption of PHP 6 too as many ISPs would be reluctant to install a version that immediately slows down the applications of their users.
</p></blockquote>
<p>I am definitely not familiar with all the issues involved, but wouldn&#8217;t this make it hard to write general purpose PHP applications?  Programs would have to check whether unicode was on or off?  Wouldn&#8217;t that checking be slow and complicated, too?</p>
<p>I think its great to discuss ways to improve adoption of PHP 6 so far ahead.  It looks like APC will be included.  I think thats great news on the adoption front.</p>
<p>I wonder, though, if anyone has gone and asked hosting companies what features they might like to see in PHP 6?  I also wonder if it would be helpful to have two upgrade guides: one for programmers and one for hosts.  Perhaps even a separate Hosting PHP Applications section as part of the PHP manual.  (With things like &#8220;How do I find out which PHP script sent out this spam?&#8221;) </p>
<p>PHP hosting concerns are not always the same as PHP programmer concerns.  Hosts are important to the adoption of PHP and throwing them some love can only be a good thing for the platform as a whole.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.procata.com/blog/archives/2005/11/22/a-glimpse-into-the-future-php-6/feed/</wfw:commentRss>
		<slash:comments>10</slash:comments>
		</item>
		<item>
		<title>Of PHP References and Compatibility</title>
		<link>http://www.procata.com/blog/archives/2005/10/20/of-php-references-and-compatibility/</link>
		<comments>http://www.procata.com/blog/archives/2005/10/20/of-php-references-and-compatibility/#comments</comments>
		<pubDate>Fri, 21 Oct 2005 05:38:29 +0000</pubDate>
		<dc:creator>Jeff</dc:creator>
				<category><![CDATA[PHP]]></category>
		<category><![CDATA[performance-optimization]]></category>
		<category><![CDATA[php-5]]></category>
		<category><![CDATA[php-references]]></category>

		<guid isPermaLink="false">http://www.procata.com/blog/?p=149</guid>
		<description><![CDATA[Following up on the Backward compatibilty and web host adoption of PHP 5 post from two weeks ago, I got a pretty good education about the problem with taking a reference of $this.  The best summary is in this bug report.
It comes down to the fact that allowing references to be taken of $this [...]]]></description>
			<content:encoded><![CDATA[<p>Following up on the <a href="http://www.procata.com/blog/archives/2005/10/02/backward-compatibilty-and-web-host-adoption-of-php-5/">Backward compatibilty and web host adoption of PHP 5</a> post from two weeks ago, I got a pretty good education about the problem with taking a reference of $this.  The best summary is in <a href="http://bugs.php.net/bug.php?id=28491">this bug report</a>.</p>
<p>It comes down to the fact that allowing references to be taken of $this can lead to unexpected values for $this later on.  ($this re-assigned)  However, it does not appear that a good solution exists:</p>
<blockquote><p>
Given the choice between: (A) doing nothing but leaving room for confusion, (B) taking away the ability to create references, or (C) checking assignments for references to $this(read: slow);  The current decision is to go with (A).
</p></blockquote>
<p>The cause of the problems were a result of diverging away from strategy A and a little bit into strategy B.  I&#8217;m still working on <a href="http://bugs.php.net/bug.php?id=34844">compiling 5.1rc3</a>, so i&#8217;m not yet sure how this was actually resolved.  I wouldn&#8217;t feel bad about a warning when this occurred.  However, I think a fatal error is absolutely wrong here.  I do feel confident this will get resolved in an acceptable manner because  I&#8217;m fairly sure that unless it becomes illegal to pass $this to a function by reference that there will always be a workaround for making code compatible with PHP 4 regarding $this.  Thanks to everyone who looked in to it.</p>
<p>In the meantime, Derrick Rethans made an article he wrote for php|architect explaining <a href="http://www.derickrethans.nl/php_references_article.php">PHP References</a> available.  You should read this article.  I had to print it to follow it, but I learned something that I did not know.  I did not know that PHP uses a copy on write semantic for normal variables.  The one question that I wish the article had covered was how objects get automatically passed by reference in PHP 5.</p>
<p>The article debunks some myths about using references for performance.  I experimented with this a bit when PHP 4 first came out, but quickly gave up on using references for optimization.  I ended up with too many mysterious bugs to track down from &#8220;magically connected&#8221; variables.  I finally ended with some fairly limited rules for using references.  I avoid them in all cases except when passing values to functions by reference and for variables that held objects, in which case I use them always.  When I want mystery i&#8217;ll go to the library, thank you.  I don&#8217;t need it in my software.</p>
<p>I&#8217;ve been looking at the changes necessary for the php 4.4/5.0.5 update.  I wrote a little <a href="http://www.procata.com/software/scanrefret/scanrefret.phps">scanner program</a> to help locate suspicious return statements.  (I&#8217;m far from E_STRICT anyway.)  But, I have no programatic help for finding &#8220;Only variables can be passed by reference&#8221; errors except to actually trigger the error.</p>
<p>I&#8217;ve been a little bit frustrated about getting over the compatibility hump with 4.4/5.0.5/5.1rc3.  But that seems like nothing compared to the ingrate who emailed Derrick <a href="http://www.derickrethans.nl/fanmail.php">fan mail</a>.  This dude needs to get a grip.</p>
<p>I don&#8217;t think the update was a mistake at all.  Like I said earlier, I&#8217;ll take my PHP without mysterious bugs, please.  Rather, I think the mistake here was in not understanding the backward compatibility issues.  I went back and read some of the <a href="http://groups.google.com/group/mailing.www.php-dev/browse_frm/thread/d50625abfe3d0383/">orginal discussion</a> about this update.  What strikes me was that binary compatibility was discussed, but no-one seemed that excited about the backward compatibility issues at the code level.</p>
<p>So a mistake was made.  These things happen.  <a href="http://www.derickrethans.nl/php_release_process.php">Steps have been taken</a> to ensure that something like this is less likely happen again.  Derrick&#8217;s fan needs to get over it and move on.</p>
<p><a href="http://www.derickrethans.nl/php_release_process.php">Along these lines</a>, It seems like with so many projects using automated testing that there should be a process for projects with automated test suites to package them up and donate them to an automated backward compatibility lab.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.procata.com/blog/archives/2005/10/20/of-php-references-and-compatibility/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>PHP Development From Java Architects Eye</title>
		<link>http://www.procata.com/blog/archives/2005/04/23/php-development-from-java-architects-eye/</link>
		<comments>http://www.procata.com/blog/archives/2005/04/23/php-development-from-java-architects-eye/#comments</comments>
		<pubDate>Sat, 23 Apr 2005 18:04:02 +0000</pubDate>
		<dc:creator>Jeff</dc:creator>
				<category><![CDATA[PHP]]></category>
		<category><![CDATA[java]]></category>
		<category><![CDATA[language-comparison]]></category>
		<category><![CDATA[performance-optimization]]></category>
		<category><![CDATA[shared-nothing]]></category>

		<guid isPermaLink="false">http://www.procata.com/blog/archives/2005/04/23/php-development-from-java-architects-eye/</guid>
		<description><![CDATA[Simple Thoughts blog has a post on PHP development from a Java architects eyes.  This post highlights the paradigm difference between programming in PHP and programming in Java:

In PHP multi-threaded programming using ticks is rather primitive, to put it politely. I couldn&#8217;t find any way to share data between multiple invocations of the script, [...]]]></description>
			<content:encoded><![CDATA[<p>Simple Thoughts blog has a post on <a href="http://blog.taragana.com/index.php/archive/php-development-from-java-architects-eye/">PHP development from a Java architects eyes</a>.  This post highlights the paradigm difference between programming in PHP and programming in Java:</p>
<blockquote><p>
In PHP multi-threaded programming using ticks is rather primitive, to put it politely. I couldn&#8217;t find any way to share data between multiple invocations of the script, without resorting to file or SQL. I missed saving in servlet context and singletons (evil!).
</p></blockquote>
<blockquote><p>
I however kept looking for a uber-global which will allow me to persist data across sessions.
</p></blockquote>
<blockquote><p>
I couldn&#8217;t find simple way to cache data in PHP. File or DB based caching was unattractive to me.
</p></blockquote>
<p>This pretty much sums up the fundamental difference.  PHP shuns threads in favor of simplicity and relies on files and databases to &#8220;share data between multiple invocations of the script.&#8221;  The author doesn&#8217;t make this paradigm shift and erroneously implies that PHP is not scalable.  At the same time, he offers this insight into the mindset of Java programmers:</p>
<blockquote><p>
I think it is because Java think-tank wants to encourage programming with resource constraints in mind. remember Java had an Oak background, a language targeted for limited resource devices.</p>
<p>The sad part is that most Java developers get bogged down by such trivialities and cannot see the forest for trees. I know, I know you are an exception.</p>
<p>Most of the time you hear Java programmers thinking of scalability and performance when his PHP counterparts are happily coding away in a world with unlimited resources (they think). Unfortunately Java developers as a group tend to get bogged down with resource conservation mindset.
</p></blockquote>
<p>There is a name for this.  It is called premature optimization.  And it often leads to code that is slower and less scalable.  <a href="http://www.procata.com/blog/archives/2004/06/30/php-scalability-and-perforamnce/">Scalable applications can be written in PHP</a>.  One just uses a different set of patterns to write them in PHP than in Java.</p>
<p>Speaking of mindset&#8230;</p>
<blockquote><p>
Overall a large part of the difference is in the mindset of a Java and PHP developer. How do you perform SQL queries in PHP? You just create a SQL statement string in code concatenating proper parameters as necessary.</p>
<p>Tell that to a Java programmers worth his salt. If he doesn&#8217;t half-die in shock, I would be surprised. &#8230; At the very least he must stow away his SQL code in a separate class and use the functionality by invoking methods in that object.
</p></blockquote>
<p>PHP pitches a large tent.  There are many amateur and professional programmers using PHP.  I don&#8217;t know many of the professionals using this technique.  Most people I know are using a data base abstraction library, such as PEAR:DB, PEAR:MDB2, or ADODB, Creole or perhaps even PDO.</p>
<p>The interesting thing is that some of the most popular PHP applications are not the ones that I would point to and tell people &#8220;this is a good example of programming in PHP.&#8221;  I won&#8217;t name names, but I would hate for people to form their opinions about PHP solely on the design of these applications.</p>
<p>I got my first paid full time programming job over the summer when I was 17 and worked as a full time professional programmer during all but two years of my college career.  Eventually I came to a realization that caused me to change my major from computer science to business.  That realization was that project success has far more to do with how closely your software meets requirements than how technically advanced it is.  I have personally witnessed far more &#8220;high architecture&#8221; projects that never finished or met the users needs than &#8220;low architecture&#8221; projects that couldn&#8217;t be made to scale when necessary.</p>
<p>That is why software built by their users, such as many visible PHP projects are, can be very successful.  They do exactly what the users would want them to do.  Then we professional programmers look under the hood and and turn a little green. However, sometimes <a href="http://www.sitepoint.com/forums/showthread.php?t=155043">worse is better</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.procata.com/blog/archives/2005/04/23/php-development-from-java-architects-eye/feed/</wfw:commentRss>
		<slash:comments>14</slash:comments>
		</item>
		<item>
		<title>Microbenchmarks of single and double qouting.</title>
		<link>http://www.procata.com/blog/archives/2005/03/08/microbenchmarks-of-single-and-double-qouting/</link>
		<comments>http://www.procata.com/blog/archives/2005/03/08/microbenchmarks-of-single-and-double-qouting/#comments</comments>
		<pubDate>Tue, 08 Mar 2005 23:20:48 +0000</pubDate>
		<dc:creator>Jeff</dc:creator>
				<category><![CDATA[PHP]]></category>
		<category><![CDATA[benchmarks]]></category>
		<category><![CDATA[performance-optimization]]></category>

		<guid isPermaLink="false">http://www.procata.com/blog/archives/2005/03/08/microbenchmarks-of-single-and-double-qouting/</guid>
		<description><![CDATA[I wrote earlier about flawed microbenchmarks.  Today on sitepoint, there was a post on the performance of single versus double quotes in PHP based on a microbenchmark:

The reasoning behind this speedup is that when the PHP compiler encounters a string constant beginning with a double quote, the string itself must be parsed and special [...]]]></description>
			<content:encoded><![CDATA[<p>I wrote earlier about <a href="http://www.procata.com/blog/archives/2005/02/24/flawed-microbenchmarks/">flawed microbenchmarks</a>.  Today on <a href="http://www.sitepoint.com/blog-view.php?blogid=9">sitepoint</a>, there was a post on the performance of single versus double quotes in PHP based on a microbenchmark:</p>
<blockquote><p>
The reasoning behind this speedup is that when the PHP compiler encounters a string constant beginning with a double quote, the string itself must be parsed and special characters (such as $, \ and {) have special meanings. By contrast, if a string constant begins with a single quote, only the backslash has a special meaning, and therefore PHP doesn&#8217;t have to worry about replacing variables and expressions embedded in the string.
</p></blockquote>
<p>This line of thought is flawed for two reasons.  </p>
<p>First, PHP uses <a href="http://www.gnu.org/software/flex/">flex</a> to tokenize the php source code.  Flex is a table driven lexer.  It doesn&#8217;t necessarily follow that having more characters with special meaning makes flex slower if you don&#8217;t actually use those characters.</p>
<p>Second, the <a href="http://insighttoinjury.com/archives/2005/02/27/php-speed-differences/">original benchmark</a> doesn&#8217;t actually measure parsing time.  Like all microtime() based benchmarks, the first access of microtime() doesn&#8217;t happen until the php file is completely parsed and converted into opcodes.  Additionally, it executed each literal inside a 10,000 iteration loop.  Thats 1 time to parse it and 10,000 times to execute it.</p>
<p>I put together a different benchmark that does measure parsing time.  It consists of two files<br />
<pre class="php">&nbsp;
<span style="color: #000000; font-weight: bold;">&lt;?php</span> <a href="http://www.php.net/echo"><span style="color: #000066;">echo</span></a> <span style="color: #ff0000;">'very long string'</span>; <span style="color: #000000; font-weight: bold;">?&gt;</span>
&nbsp;</pre><br />
and<br />
<pre class="php">&nbsp;
<span style="color: #000000; font-weight: bold;">&lt;?php</span> <a href="http://www.php.net/echo"><span style="color: #000066;">echo</span></a> <span style="color: #ff0000;">&quot;very long string&quot;</span>; <span style="color: #000000; font-weight: bold;">?&gt;</span>
&nbsp;</pre></p>
<p>The very long string I used was the text of the US constitution: 27,787 bytes.  I measured using ab, which includes parsing time.  My results:</p>
<p>single quotes: 27.59 ms<br />
double quotes:  27.74 ms</p>
<p>Hardly earth-shattering. Single quotes was consistently faster, but by the same minor margin.  This is with a 27k literal string. My guess is that you will never have enough literals in a typical PHP program for any parsing performance differential to matter.</p>
<p>Is there an execution differential?  Do both of these constructs generate the same opcodes?  I tried to check it out using <a href="http://www.derickrethans.nl/vld.php">Vld</a> or <a href="http://us4.php.net/ref.parsekit">parsekit</a> but I can&#8217;t get either of these to work in my development environment (OS X).  Perhaps someone will reply in a comment with the opcodes for the previous two programs and settle the question.</p>
<p>There doesn&#8217;t seem to be much if any difference between single and double quotes for an identical string.  A more interesting question would be what happens when the strings aren&#8217;t identical.  Consider the following three examples:<br />
<pre class="php">&nbsp;
<span style="color: #000000; font-weight: bold;">&lt;?php</span> <a href="http://www.php.net/echo"><span style="color: #000066;">echo</span></a> <span style="color: #ff0000;">&quot;Answer: $answer!&quot;</span>; <span style="color: #000000; font-weight: bold;">?&gt;</span>
&nbsp;</pre><br />
versus<br />
<pre class="php">&nbsp;
<span style="color: #000000; font-weight: bold;">&lt;?php</span> <a href="http://www.php.net/echo"><span style="color: #000066;">echo</span></a> <span style="color: #ff0000;">'Answer: '</span>, <span style="color: #0000ff;">$answer</span>, <span style="color: #ff0000;">'!'</span>; <span style="color: #000000; font-weight: bold;">?&gt;</span>
&nbsp;</pre><br />
or<br />
<pre class="php">&nbsp;
<span style="color: #000000; font-weight: bold;">&lt;?php</span> <a href="http://www.php.net/echo"><span style="color: #000066;">echo</span></a> <span style="color: #ff0000;">'Answer: '</span> . <span style="color: #0000ff;">$answer</span> . <span style="color: #ff0000;">'!'</span>; <span style="color: #000000; font-weight: bold;">?&gt;</span>
&nbsp;</pre><br />
or<br />
<pre class="php">&nbsp;
Answer: <span style="color: #000000; font-weight: bold;">&lt;?php</span> <a href="http://www.php.net/echo"><span style="color: #000066;">echo</span></a> <span style="color: #0000ff;">$answer</span>; <span style="color: #000000; font-weight: bold;">?&gt;</span>!
&nbsp;</pre><br />
Which one do you think is faster?  </p>
<p>My gut feeling is that concatenation is slower because of the ability of the output buffer to allocate memory in big chunks rather than little chunks.  Other than that, I honestly don&#8217;t think it makes a difference, but I would love to compare the opcodes for each of these examples.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.procata.com/blog/archives/2005/03/08/microbenchmarks-of-single-and-double-qouting/feed/</wfw:commentRss>
		<slash:comments>12</slash:comments>
		</item>
		<item>
		<title>PHP Scalability and Performance</title>
		<link>http://www.procata.com/blog/archives/2004/06/30/php-scalability-and-perforamnce/</link>
		<comments>http://www.procata.com/blog/archives/2004/06/30/php-scalability-and-perforamnce/#comments</comments>
		<pubDate>Wed, 30 Jun 2004 18:19:55 +0000</pubDate>
		<dc:creator>Jeff</dc:creator>
				<category><![CDATA[PHP]]></category>
		<category><![CDATA[performance-optimization]]></category>
		<category><![CDATA[php-scalability]]></category>

		<guid isPermaLink="false">http://www.procata.com/blog/archives/2004/06/30/php-scalability-and-perforamnce/</guid>
		<description><![CDATA[Troutgirl seems to have hit a hot button in her blog about Friendstar switching from JSP to PHP.  This story has been picked up by a variety of bloggers. I originally saw it from Dynamically typed. Russell Beattie Notebook has some good discussion on the topic.  Joe Grossberg talks about a redirection problems [...]]]></description>
			<content:encoded><![CDATA[<p>Troutgirl seems to have hit a hot button in her blog about <a href="http://troutgirl.com/blog/index.php?/archives/22_Friendster_goes_PHP.html">Friendstar switching from JSP to PHP</a>.  This story has been picked up by a variety of bloggers. I originally saw it from <a href="http://www.sitepoint.com/blog-post-view.php?id=178339">Dynamically typed</a>. <a href="http://www.russellbeattie.com/notebook/1007901.html">Russell Beattie Notebook</a> has some good discussion on the topic.  <a href="http://www.joegrossberg.com/archives/001566.html">Joe Grossberg</a> talks about a redirection problems with the switch over and adds a link to <a href="http://www.scottandrew.com/delimiter/2004_06.html#001043">Scott Andrew</a> who talks about standards compliance of the new design.  The consensus is that the new version is faster.</p>
<p>I hope that more information will come out about this.  It would be nice to have another large scale case study alongside the Yahoo talks: <a href="http://talks.php.net/show/lt2004-lamp">Large Scale PHP</a>, <a href="http://public.yahoo.com/~radwin/talks/one-year-of-php-oscon2003.htm">One year of PHP at Yahoo</a>, and <a href="http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm">Making the case for PHP at Yahoo</a>.</p>
<p>Another interesting case study is the <a href="http://ian.gaiaonline.com/forum/index.php">Gaia Online</a> discussion board.  One of the largest forums on the net, on a recent check, it claims to have 70 million messages online with roughly 9,000 simultaneous users, and 750,000 registered users.  The <a href="http://www.sitepoint.com/forums/showthread.php?t=170684&#038;highlight=phpbb">sitepoint post</a> that brought this to my attention claims they are getting over 700,000 new posts per day.  All of this running on a modified version of open source <a href="http://www.phpbb.com/">phpBB</a>.  <a href="http://www.big-boards.com/int.php?n=60">Here is an interview</a> with the board owner and founder.</p>
<p>The thread that talks about the <a href="http://www.phpbb.com/phpBB/viewtopic.php?t=135383">modifications to phpBB</a> to support Gaia Online&#8217;s volume is very interesting.  It focuses mostly on query optimization.  Not surprising in light of the previous discussion on PHP&#8217;s shared nothing architecture.  If PHP encourages moving concurrency management to the database, then application scalability is going to become a matter of database scalability.</p>
<p>Switching from scalability to performance, John Lim talks about his experiences <a href="http://phplens.com/phpeverywhere/?q=node/view/52">optimizing PHP code using xdebug</a>.  His article makes me want to check out xdebug, but I have too much on my plate right now to even risk getting near my PHP configuration.  I am hoping that I will have time to do this before the upcoming WACT release.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.procata.com/blog/archives/2004/06/30/php-scalability-and-perforamnce/feed/</wfw:commentRss>
		<slash:comments>11</slash:comments>
		</item>
	</channel>
</rss>
