On Tue, Oct 6, 2009 at 12:25 PM, Andrea Giammarchi <an_red@xxxxxxxxxxx> 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@xxxxxxxxxxxxx >> From: tedd.sperling@xxxxxxxxx >> Subject: RE: 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
