On Tue, Oct 6, 2009 at 12:25 PM, Andrea Giammarchi <an_...@hotmail.com> wrote:
> er ... tedd, whatever, usually ++i is faster in almost every language, and 
> even C developers could use these kind of micro optimizations.
> Speed, even in this SuperCPU era, is still relevant, we would not need 
> benchmark to compare programming languages for each purpose.
> Of course in a crappy application, the usage of ++i rather than i++ won't 
> make any difference, but specially for that kind of for loop where there is 
> absolutely no harm or side-effect using ++i rather than i++ ... if ++i could 
> be 0.0001% nobody have a valid reason to avoid it.
> Put in this way: I need to do the same thing, one could be better ... why on 
> earth should I use the other way?
> I just develop applications, where I can micro-optimize, I do it ... I have 
> never had speed problems, but maybe I am just lucky.
> Regards
>> Date: Tue, 6 Oct 2009 12:15:54 -0400
>> To: php-general@lists.php.net
>> From: tedd.sperl...@gmail.com
>> Subject: RE: [PHP] Whacky increment/assignment logic with $foo++ vs ++$foo
>> At 3:56 PM +0200 10/6/09, Andrea Giammarchi wrote:
>> >  > Does these behaves exactly?
>> >>  for($i=0; $i<10; ++$i)
>> >>  for($i=0; $i<10; $i++)
>> >
>> >different benchmarks showed ++$i is usually faster than $i++
>> "Faster" is a relative term that is becoming more meaningless each year.
>> Considering that "speed" is increasing and "memory" prices are
>> dropping exponentially, both of those are becoming less and less
>> important in design considerations (my opinion).
>> The speeds of the Crays of yesteryear we are now holding in our hands
>> as cell phones. The memory we are buying today is literally fractions
>> of a cent of the tens of thousands of dollars we spent some 20 years
>> ago.
>> I venture to claim the time it took me to write this email (and for
>> you to read it) was longer than the total time saved between using
>> ++$i vs $i++ for all the php scripts in the world over the remaining
>> life span of PHP.
>> Interesting "food for thought", huh?
>> Cheers,
>> tedd
>> --
>> -------
>> http://sperling.com  http://ancientstones.com  http://earthstones.com
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
> _________________________________________________________________
> Windows Live: Make it easier for your friends to see what you’re up to on 
> Facebook.
> http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009

The problem with PHP micro-optimizations like that or ' vs. " is that
PHP rarely bottlenecks a PHP/MySQL application (actually if you run a
dedicated box, see how often your CPU hits 100%, it won't be very
often for the vast majority of PHP/MySQL sites which are more likely
to be disk i/o bound than cpu bound).  The time spent in PHP (by PHP,
not by the database) for page generation is completely negligible and
invisible behind the overhead of network protocols for the vast
majority of sites or drowned in the performance killing of SQL.  I
would probably go so far as to say it doesn't matter how quickly your
PHP runs; you'd save as much time tuning one slow query as you would
micro-optimizing every line of your codebase.  Furthermore, the amount
of time micro-optimization takes up (going through old code, I mean)
could be better spent doing something that actually does increase your
performance, like implementing a search engine or memcached.  Going
forward, if you're aware that ++i and i++ are the same for your
application and ++i is a single php opcode faster (which I don't know
if it's even measurable, that difference), sure go ahead and use ++i
but it's certainly not worth serious thought or developer time.

My two cents.

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to