On Thu, Nov 20, 2008 at 12:33 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> Don't quite understand why eliminating three branches is worth the comment > "compiler-as-it-happened-to-behave-last-time-I-checked", but happy to take > it out. Have you actually tested it on a JS interpreter? Even in the case of C, a good compiler will use branch prediction to arrange it such that the common case (either inferred from the style, profile-directed compilation, or programmer annotations) is untaken branches, which on a modern processor is just as fast as the or. load a into accum bnz trueLabel load b into accum bnz trueLabel load c into accum trueLabel: return accum compared to load a into accum load b into temp or temp load c into temp or temp return accum In either case, the loads are going to dominate execution time and untaken branches are no more expensive than the or. The first version will be much faster when the first or second is true, and equally fast when all are false (ignoring the fact that the first version has an instruction that can be put into the load's delay slot while the second one will stall for the first load to finish before starting the second). However, in JS, evaluating the expression is done in complicated code with lots of branches already. I am not sure that it is any slower at all to evaluate a || b than a | b, even if the values are known to be false. Finally, I think it requires a demonstrable improvement to justify ignoring the typical programming idiom, and if that is found it should be documented there, such as "IE is 5 times faster to use | rather than || here, [EMAIL PROTECTED] OrBenchmark}". -- John A. Tamplin Software Engineer (GWT), Google --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
