Page 2 of 2

Posted: Thu Oct 26, 2006 12:09 am
by Cameri
I ran some tests on my computer and these were the results:
http://cameri.dnsalias.com/cameri/color ... edtest.jpg

Code: Select all

Mean (bitwise and):		0.00041713714599609
Mean (boolean negation):		0.00038960933685303
Mean (modulus):		0.00042844772338867
Mean (xor):		0.00036680221557617
Standard deviation (bitwise and): 9.9224554222463E-006
Standard deviation (boolean negation): 6.6833636537498E-006
Standard deviation (modulus): 9.6096878918103E-006
Standard deviation (xor): 5.5752548212973E-006

Posted: Thu Oct 26, 2006 12:27 am
by s.dot
Given that chart, the comparison between the fastest and the slowest method is 1/10000th of a second. Doesn't look like it matters much!

Posted: Thu Oct 26, 2006 12:42 am
by timvw
You might want to take into consideration that a boolean can only take two values.. Which makes it useless for situations with more than two values ;)

If the number of situations is a power of two, adding a bit each cycle will probably be the most efficient... In other situations you'll really have to compare the index and maximum...

The last time i looked it up in the instruction set a modulo operation was more expensive than a compare and add operation.. But that's at the level of instruction sets... For use in a PHP environment the performance differences would most certainly not be the reason i choose one over the other...

Posted: Thu Oct 26, 2006 1:17 am
by alex.barylski
timvw wrote:You might want to take into consideration that a boolean can only take two values.. Which makes it useless for situations with more than two values ;)
Perhaps...but 95% of record sets I see displayed follow a pattern of typically 2 or none...rarely do I see 3 or more different colored rows...so bitwise works just fine ;)
timvw wrote: If the number of situations is a power of two, adding a bit each cycle will probably be the most efficient... In other situations you'll really have to compare the index and maximum...
Huh...adding a bit? Why would you need to add a bit? You use a normally stepped counter (1,2,3,4 and so on) using the ++ operator or whatever method you choose. All odd numbers have the first bit set...all even don't...I fail to see your point?

I think what your recalling is that on 80x86 machines it was an assembly trick that shifting left or right would either divide or multiply by two. In which case mult/div operations on numbers of the power of two were faster than using the actual arithmetic instructions. A bitwise operation like I've suggested above...works regardless of whether the number is a power of two or not. It simply checks the first bit of a byte for ON/OFF state...yes it's boolean, but I like said, how many applications do you know of which use more than 2 colors? I can't list (m)any :P
timvw wrote: The last time i looked it up in the instruction set a modulo operation was more expensive than a compare and add operation.. But that's at the level of instruction sets... For use in a PHP environment the performance differences would most certainly not be the reason i choose one over the other...
Yes it's at the level of instructions sets...but that knowledge is what makes you an experienced developer and lets you make decisions which further enhance your code...anyone who would argue that a simple bitwise check is more difficult than modulus...I dunno...maybe they should be programming...cause as long as you understand how binary works...it makes total sense. :)

I wouldn't go out of my way to optimize my code, but little caveats, like single quotes over double quotes...it's a split second decision which I either accept or refuse. Alone maybe it's nothing, but accumulated over a period of 30 days on a high use web site...those little tricks add up ;)

Cheers :)

Posted: Thu Oct 26, 2006 6:45 am
by johno
Guys I don't really want to offend you, but you are wasting your time on absolutely senseless optimizations. Suppose you have table with 1000 rows (pretty unrealistic but anyways). So if you use xor instead of modulus you gain 1000*0.00008sec = ~0.08sec.

Now try to make a query to your database that returns 1000 rows needed for that table. How long does this takes? How much is that compared to 0.08sec?

Now open up your browser, open the page that contains this big table. How long does it takes to load it? Did you noticed that 0.08sec difference?

Lastcraft on sitepoint.com was talking about this and really opened my eyes time ago.

http://www.sitepoint.com/blogs/2005/03/ ... mment-1964
http://www.sitepoint.com/forums/showpos ... stcount=50

On the other hand there are some special cases when you need to know about these little optimizations.

One such example from my experience (slightly offtopic). I was doing some profiling for FSHL (a fast syntax highlighter written in PHP). First tests showed that the bottleneck was strlen() called many many times. So I bypassed it somehow by counting characters (because the state machine did that anyways) and gained about 20% faster time.

Another optimization was about that state machine concatenates lots of strings. PHP don't likes that and does lots of memory copying and allocation. So we buffered these strings in an array and then if a magic size threshold was met we imploded that array into one string. We were really surprised by result.

Posted: Thu Oct 26, 2006 10:48 am
by alex.barylski
Fare enough.

I won't (and I don't think timvw will either) argue that *best* optimizations usually come from algorithms or implementations...thats common sense.

The point that I was making, is that accumulated trivial optimizations *do* indeed add up. Maybe it's just me, but I am of the mindset that optimizations are best left for the end of a project development life cycle. I don't refactor anything until everything appears to work well (most of the times). I do however capitalize on trivial optimizations, as they are easy to utilize, don't break code and require minimal if any refactoring.

To me, it seems almost borderline naive that a professional developer would discard such trivial changes, just because at first glance they don't appear to be worth the hassle...

Where is the hassle in using single quotes over double quotes? Yes the performance increase is negligible, but the fact is, it exists, so why not take advantage of it?

IMHO it has more to do with programmer stubborness or complacency than anything else.

Bottom line: Yes, trivial tweaks are barely noticable. But like a wasp, there is power in numbers :P

Cheers :)

Posted: Thu Oct 26, 2006 11:38 am
by RobertGonzalez
timvw wrote:You might want to take into consideration that a boolean can only take two values.. Which makes it useless for situations with more than two values ;)
The reason that was offered as a solution was because the OP asked 'What's the best approach to Coloring Even And Odd Rows?'. Odd or even is essentially boolean.

Posted: Thu Oct 26, 2006 2:49 pm
by alex.barylski
Everah wrote:
timvw wrote:You might want to take into consideration that a boolean can only take two values.. Which makes it useless for situations with more than two values ;)
The reason that was offered as a solution was because the OP asked 'What's the best approach to Coloring Even And Odd Rows?'. Odd or even is essentially boolean.
Very TRUE...or is that FALSE :P

No pun intended :P

Posted: Thu Oct 26, 2006 3:42 pm
by timvw
Ambush Commander wrote:I'm not sure what timvw is referring to, but is he talking about something like:

Code: Select all

$row = 0;
while ( ... ) {
  $even = $row % 2;
  if ($even) {
     $row = 0;
     // ...
  } else {
    // ...
  }
}
Which, if you really think about it, doesn't seem to have any positive performance effect...
I was most certainly not talking about that situation, because it wouldn't remove the modulo operation.. I was more thinking along the lines:

Code: Select all

while (...) {
 switch($number) {
   case 1: 
    // do stuff
    break;
   case 2:
    // do stuff
    break;
   ...
   case n: 
     // do stuff
     $number = 0; 
     break;
  }
  ++$number;
}

Posted: Thu Oct 26, 2006 3:46 pm
by timvw
Everah wrote:
timvw wrote:You might want to take into consideration that a boolean can only take two values.. Which makes it useless for situations with more than two values ;)
The reason that was offered as a solution was because the OP asked 'What's the best approach to Coloring Even And Odd Rows?'. Odd or even is essentially boolean.
Since the third post in this thread the topic was already broader than odd/even... So i don't see what bothers you about my statement...

Posted: Thu Oct 26, 2006 3:52 pm
by Cameri
Well, nobody here is forced to do anything a certain way. IF you are smart enough, you'll choose what you think it's best given the opinions of the other gurus here, and given the scenario you are working in, whether it's a big scale application or not.

Posted: Thu Oct 26, 2006 4:01 pm
by RobertGonzalez
timvw wrote:
Everah wrote:
timvw wrote:You might want to take into consideration that a boolean can only take two values.. Which makes it useless for situations with more than two values ;)
The reason that was offered as a solution was because the OP asked 'What's the best approach to Coloring Even And Odd Rows?'. Odd or even is essentially boolean.
Since the third post in this thread the topic was already broader than odd/even... So i don't see what bothers you about my statement...
Nothing bothers me about your statement. I think it is noteworthy and deserves to be said/read. I was only pointing out that, though this thread seemed to move beyond the scope of odd/even, the original poster never moved off his original question, which was what is the best way to color even or odd rows.

There are quite a few solutions out there for coloring varying pieces of repeated data. Some I have learned from you. I was just saying that the user asked specifically about switching back and forth between two properties, which most of us know is almost to the letter what a boolean is. Is a boolean checker useless for more than two values? Absolutely. Was the OP asking about more than two values? No. That is all I am saying. I meant no offense by it.