Page 2 of 4

Posted: Sat Apr 15, 2006 1:06 pm
by Ambush Commander
In anycase, I know what your talking about, but I think what most seasoned professionals are getting at when they heckle, is more geared towards algorithm optimization than trivial optimizations like the one mentioned above. Alot of development time is wasted when you spend all day optimizing one function, when really you can't truly tell if that function needs optimization until you have a fully functioning application.
Erm... profiling? Benchmarking? Anyone?

Posted: Sat Apr 15, 2006 1:20 pm
by Christopher
BDKR wrote:Well I happen to agree with this. It's funny, but in times past on this board and other places around the net, you would have been (speaking from experience) heckled and labeld a code smith or guilty of such sins as "pre-mature optimization". As it turns out, these mooks are all reading from the same playbook.
I'll heckle. Pre-mature optimization is a real problem, and being experienced enough to know that you don't know is the point of it. The problem with this comment:
Hockey wrote:you should optimize when it's obvious
... is that in hindsight the obvious can look just plain wrong.

Let's be clear: if you are not spending additional time or basing your code on future assumptions that you are not positive about, then it's not pre-mature optimization.

Posted: Sat Apr 15, 2006 1:41 pm
by alex.barylski
arborint wrote:
BDKR wrote:Well I happen to agree with this. It's funny, but in times past on this board and other places around the net, you would have been (speaking from experience) heckled and labeld a code smith or guilty of such sins as "pre-mature optimization". As it turns out, these mooks are all reading from the same playbook.
I'll heckle. Pre-mature optimization is a real problem, and being experienced enough to know that you don't know is the point of it. The problem with this comment:
Hockey wrote:you should optimize when it's obvious
... is that in hindsight the obvious can look just plain wrong.

Let's be clear: if you are not spending additional time or basing your code on future assumptions that you are not positive about, then it's not pre-mature optimization.
I'm not sure I follow you on that one :?

I agree that pre-mature "anything" is a bad thing, even optimizing code :P

Not so much it's a bad thing, but can be, but more likley just unnessecary.

Just because a functions code is time consuming, if it's only called 3 times in a typical application instance, who cares about opitmizing it - it's a waste of time.

I personally use a rule of thumb I call the 90/10 rule where 90% of my codebase gets only 10% optimization efforts and visa versa.

Posted: Sat Apr 15, 2006 1:43 pm
by alex.barylski
Ambush Commander wrote:
In anycase, I know what your talking about, but I think what most seasoned professionals are getting at when they heckle, is more geared towards algorithm optimization than trivial optimizations like the one mentioned above. Alot of development time is wasted when you spend all day optimizing one function, when really you can't truly tell if that function needs optimization until you have a fully functioning application.
Erm... profiling? Benchmarking? Anyone?
It was kind of assumed that one would use a profiler :P

Posted: Sat Apr 15, 2006 1:46 pm
by Ambush Commander
Hmm... so we shouldn't change code to prematurely optimize, but changing syntax to prematurely optimize is a good thing?

Just for the record, do you use $i++?

Posted: Sat Apr 15, 2006 2:10 pm
by AKA Panama Jack
Hockey wrote:Just because a functions code is time consuming, if it's only called 3 times in a typical application instance, who cares about optimizing it - it's a waste of time.

Now I will have to totally disagree with you on that one when it comes to web based applications.

It may not sound like much to have a slow, bloated piece of code that only gets called 3 times or even once in a typical application instance but when you multiply that by the number of page views that activate the application per second then you have a really BIG problem. Especially when the site is very active. Sure you can throw hardware at the problem but that only masks it and in a shared hosting environment it becomes critical pretty fast.

The one thing that has always irked me about programmers anymore is how many if not most of them totally ignore optimization in favor of "Make the damned thing work and move on quickly.". It really doesn't take that much extra time to make sure your code is optimized in the first place. The more experienced you become at it the faster and easier it is to create optimized code from the start. That's much faster than slapping together something that works and then trying to figure out what needs to be sped up later.

When it comes to programming, premature optimization is a good thing. Unlike in other areas. :twisted:

That's why I have been developing alternatives to ADOdb and Smarty. They are highly optimized and the sites we host that use them can offer more pages per second at a greatly reduced server load.

Starts Chanting "Optimization Now!"

;)

Posted: Sat Apr 15, 2006 2:13 pm
by alex.barylski
Ambush Commander wrote:Hmm... so we shouldn't change code to prematurely optimize, but changing syntax to prematurely optimize is a good thing?

Just for the record, do you use $i++?
Well I don't make any changes, cuz I don't use double quotes, but always single quotes. It's a conscienous effort but it's still optimizing.

Nine times out of ten I use ++ operator as opposed to writing the whole thing out yes...

But thats only because I favour code readability over code optmization 9 out of 10 times.

Why does PHP have some quirk where $i = $i + 1; is more efficient?

Posted: Sat Apr 15, 2006 2:26 pm
by Ambush Commander
Why does PHP have some quirk where $i = $i + 1; is more efficient?
Nope. ;-) ++$i (preincrement) is faster. This because of the return values of the post/pre increment.

Code: Select all

$i = 0;
echo $i++; // 0
echo $i; // 1
echo ++$i; //2
This is a peephole optimization that optimizers like Zend Optimizer do. Another quirk: define() and defined() are DEAD SLOW. But there really isn't any alternative to them. Constants are quite useful. How about includes and requires? They can be quite slow sometimes, so one might wonder why not just inline them all.
It may not sound like much to have a slow, bloated piece of code that only gets called 3 times or even once in a typical application instance but when you multiply that by the number of page views that activate the application per second then you have a really BIG problem.
Actually, it would be a problem even without lots of page views. If you were to try profiling the page with the bloated piece of code, you'd notice that the slow code would be taking up most of the execution time. That means... optimize!
The one thing that has always irked me about programmers anymore is how many if not most of them totally ignore optimization in favor of "Make the damned thing work and move on quickly."
There is a third medium: slow but well written code. That is, the logic is easy to understand, there's no optimization black magic going on, easily refactorable. If you get an API, then you can refactor till the cows come home inside the API in order to optimize. Sometimes that means completely rewriting the code.

Here's the thing: you're right (but only about your specific cases). You've been developing alternatives to ADOdb and Smarty, because you know the APIs, you know what should be going on, you've got clear test-cases. Smarty and ADOdb are fairly common patterns, and you'll see them in most applications (even if it's not the same implementation).

If you were building something unique, novel and complex, optimizing immediately may not be the best idea, especially if you realize that you got the spec again and are now faced with the need to extend heavily optimized code (not the most pleasant endeavor).

One last thing: optimization can mean removing bloat. For instance, with ADOdb, I almost never use any of the other functions besides execute() and getArray(). Even though the library claims to be built like an onion, one can still create a barebones database wrapper that just does database binding and no more and will run faster. Pre-packaged solutions tend to have everything and the kitchen sink. Sometimes, the key is not rewriting: it's removing.

I'll take code that's slow but has a well defined API and is easy to read to fast code that's slightly fuzzy on the first day. Then, if need be, I'll optimize.

Posted: Sat Apr 15, 2006 2:33 pm
by feyd
I think you guys are wondering a bit off the topic now.

Posted: Sat Apr 15, 2006 2:34 pm
by alex.barylski
AKA Panama Jack wrote:
Hockey wrote:Just because a functions code is time consuming, if it's only called 3 times in a typical application instance, who cares about optimizing it - it's a waste of time.

Now I will have to totally disagree with you on that one when it comes to web based applications.

It may not sound like much to have a slow, bloated piece of code that only gets called 3 times or even once in a typical application instance but when you multiply that by the number of page views that activate the application per second then you have a really BIG problem. Especially when the site is very active. Sure you can throw hardware at the problem but that only masks it and in a shared hosting environment it becomes critical pretty fast.

The one thing that has always irked me about programmers anymore is how many if not most of them totally ignore optimization in favor of "Make the damned thing work and move on quickly.". It really doesn't take that much extra time to make sure your code is optimized in the first place. The more experienced you become at it the faster and easier it is to create optimized code from the start. That's much faster than slapping together something that works and then trying to figure out what needs to be sped up later.

When it comes to programming, premature optimization is a good thing. Unlike in other areas. :twisted:

That's why I have been developing alternatives to ADOdb and Smarty. They are highly optimized and the sites we host that use them can offer more pages per second at a greatly reduced server load.

Starts Chanting "Optimization Now!"

;)
This argument is endless...

I generally try and get a balance between the two worlds...but it's difficult at best...

I agree with your argument towards web based applications, I can see how my original point could be taken wrong. What I meant however, was regardless of platform or medium, when you profile, as a general rule of thumb you should only concern yourself with the top 10% code bottle necks, the rest is overkill...

At one time, I was hardcore into writing everything as efficient as possible, then it dawned on me how much time I was loosing optimizing "everything" and being far too zelous.

At this point I re-considered my stance from two perspectives:
1) A programmer
2) A business man

In order to keep programming I needed to keep making money and from a business perspective spending more time than nessecary on writing lighting fast code doesn't make sense.

If performance is that big an issue, why program in PHP at all?

Premature optimization can actually be a bad thing, especially for newbies or people who don't plan...

What happens if you write out 30 functions, spend a week optimizing each function and when the application is complete and released you realize that 5 of those 30 functions aren't even needed, so you refactor your code and loose 5 functions you spent 5 days tweaking???

What happens if your function interface changes? You refactor your code again and now your optimizations go to hell and you have to start again?

Those are my arguments towards pre-mature optimization...sure proper planning and experience can assist in preventing that, but it's not 100%.

IMHO it's best to save optimization for the very last or at least when you are absolutely certain you need that function/class, etc and know it's interface won't change.

Cheers :)

Posted: Sat Apr 15, 2006 6:45 pm
by shiznatix
and now with the variable inside the quotes test:

Code: Select all

<?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', TRUE);

function microtime_float()
{
    list($usec, $sec) = explode(' ', microtime());
    return ((float)$usec + (float)$sec);
}

    $times = array();
    $times['single'] = 0;
    $times['double'] = 0;

    for ($i = 0; $i < 100; ++$i)
    {
        $var = 'yesyesyes';
        $start = microtime_float();
        echo "How are you today? $var <br/>";
    
        $times['double'] += (microtime_float() - $start);

        $start = microtime_float();
        echo 'How are you today? '.$var.' <br/>';
        $times['single'] += (microtime_float() - $start);
    }
    
    echo 'Results for single quotes: ' . $times['single'] . "\n";
    
    echo 'Results for double quotes: ' . $times['double'] . "\n";
?>
the results for the amount of times i loop this through:

100 loops:
Results for single quotes: 0.00135159492493 Results for double quotes: 0.0132329463959

500 loops:
Results for single quotes: 0.00712060928345 Results for double quotes: 0.0137965679169

1000 loops:
Results for single quotes: 0.0409712791443 Results for double quotes: 0.179678440094

10000 loops:
Results for single quotes: 1.01814103127 Results for double quotes: 0.339799642563

EDIT:
100000 loops:
Results for single quotes: 14.5458409786 Results for double quotes: 2.76097488403 (WHOA! DIFFERENCE!)

Soo..... ya if you do only some loops of it then its cool. if you do many many loops then you are better off using double quotes. Sence make this not?

Basically the results say: no real different in the two. Use what you prefer. I myself like the single quotes because you can view the code better in the editor with single quotes with variables in it.

Edit to my results;
are double quotes really better than single quotes? i mean i don't know when I have looped through anything more than 100 times but still, look at the 100000 loops benchmark...should I be changing my style?

my 2 cents

Posted: Sat Apr 15, 2006 6:56 pm
by Ambush Commander
Here be my results:

100 loops
Results for single quotes: 0.0077250003814697 Results for double quotes: 0.013329744338989

500 loops
Results for single quotes: 0.12187552452087 Results for double quotes: 0.24181485176086

1000 loops
Results for single quotes: 0.23714733123779 Results for double quotes: 0.2214937210083

10000 loops
Results for single quotes: 2.4672722816467 Results for double quotes: 2.5089695453644

100000 loops
Results for single quotes: 42.336568593979 Results for double quotes: 46.356001853943

Note that this was done on a home machine with a bazillion other things going on in the background. A production server would do much better.

Edit - My verdict: it varies according to platform. On my home platform, single quotes won out every single time except 1000 (a quirk, but just goes to show...)

Posted: Sat Apr 15, 2006 6:59 pm
by shiznatix
Note:
My tests where done on a crap laptop with a shotty HD running very few processes, other than webserver stuff... gEdit, Konsole, Gaim, Firefox (freshly started firefox with only 3 tabs).

I don't know why my results where so favorable of the double quotes but Commander...did you test with a variable in it?

Posted: Sat Apr 15, 2006 7:00 pm
by Ambush Commander
I used your test. :-D (edit: by the way, it took forever for mine to finish. Looks like your crap laptop is a lot better then my crap desktop.)

Edit: More info: Windows XP SP2 running Winamp, Ultraedit, Cmd.exe, 2 explorer windows, Firefox with 4 tabs, Thunderbird, Skype, ClearSign tray, OpenOffice quickstart, Apache, MySQL, Norton Internet Security and Zone Alarm Firewall.

PHP 5.1.2 was used to run the test, and they were binaries compiled by the PHP group.

Running on a Dell DIMENSION DIM2400, Pentium 4 CPU 2.20GHz with 512 MB of RAM.

Posted: Sat Apr 15, 2006 7:29 pm
by Benjamin
I think the time differences in shiznatix's script is more due to the concentation rather than the single or double quotes. Might want to try using comma's for the single quotes rather then a .