- For what it's worth, some of the code I write does indeed run in a tight loop many times (striving for 60 frames/sec), and low-level optimizations have proven to help (especially in IE).

For curiosity's sake, I did some testing between bit-shifting and regular math, and it seems bit-shifting is in fact faster for the cases I use.

Using these two functions, with i going from 0 to 50000:

function pow2BitShifting(i) {

var x = 1 << (i % 30);

}

function pow2RegularMath(i) {

var x = Math.pow(2, (i % 30));

}

In Firefox:

Powers of 2 w/ bit shifting: 38 msecs

Powers of 2 w/ regular math: 69 msecs

In IE:

Powers of 2 w/ bit shifting: 56 msecs

Powers of 2 w/ regular math: 107 msecs

In Chrome and Safari (nearly identical here):

Powers of 2 w/ bit shifting: 2 msecs (!!)

Powers of 2 w/ regular math: 16 msecs

So anyway, it's clear that using bitwise operators has its place, so to get back to the original topic, it would be great if I could opt-in on a per-function basis. =)

Aseem

--- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@...> wrote:

>

> Sure. Write what is understood best. That's what code quality is about, I think.

> I just wanted to mention that bitwise operators in Javascript are not as efficient as in other languages (because I read bitwise and optimized so close to one another). And often are used for gaining performance only.

> And I thought of something like this:

> var x = 2;

> x * 2 === x << 1;

>

> If there is a context where bitwise is a clear and short solution to a problem, use it.

>

> Christian

>

>

> --- In jslint_com@yahoogroups.com, Paul Novitski <paul@> wrote:

> >

> >

> > >--- In jslint_com@yahoogroups.com, "christian.wirkus"

> > ><christian.wirkus@> wrote:

> > > > Are you sure bitwise operators optimize anything in Javascript?

> > > > Javascript isn't C, and the data type number is 64 bit float, not integer.

> >

> > At 9/2/2009 10:24 AM, aseem.kishore@ wrote:

> > ...

> > >I'm also not sure about whether that indeed optimizes anything. I

> > >haven't done profiling comparisons; I'm just reusing well-known algorithms.

> >

> >

> >

> > Christian, my guess is that the reasoning behind your comment is an

> > assumption that Aseem would choose bit-manipulation primarily to

> > optimize the code on a low level. From Aseem's reply that doesn't

> > appear to be the case. He's using algorithms because they're

> > dependable and do the job without regard for how they work on a low

> > level, and that's interesting.

> >

> > I offer the opinion that, unless a particular language structure

> > occurs in a loop that iterates an enormous number of times, low-level

> > optimization is irrelevant compared to the importance of its

> > usability in the high-level script.

> >

> > (Can we get away with calling usability high-level or human-level

> > optimization?)

> >

> > If a bit of syntax is easy to use, read, proofread, and modify, then

> > it wins. The whole purpose of high-level scripts such as JavaScript

> > is their human benefit only; the computers don't care, they would run

> > binary machine code much more quickly. But these days the chips are

> > so bloody fast that it takes a lot of inefficiency to make their

> > round trips perceptible to our own slow-poke bags of brain jelly.

> >

> > Regards,

> >

> > Paul

> > __________________________

> >

> > Paul Novitski

> > Juniper Webcraft Ltd.

> > http://juniperwebcraft.com

> >

> - On 04/09/09 22:01, aseem.kishore@... wrote:
> --- In jslint_com@yahoogroups.com, Stefan Weiss <weiss@...> wrote:

Much better, thank you. I didn't have the time to cook up a test myself

>> That's not really a fair comparison. The second function has to do a

>> lookup for 'Math', find its 'pow' property, and execute a method call to

>> Math.pow.

>>

>> So yes, in this case, bit shifting is faster than a call to Math.pow

>> with base 2, but that doesn't prove that the bit operations themselves

>> are handled efficiently in JS.

>

> Fair point. Since that's my use case, it's a valid comparison for my

> scenario (even if I cache a local reference to Math.pow first, the

> numbers are almost identical, so apparently the bottleneck isn't the

> lookups).

>

> But to make a more fair comparison for the purposes of the underlying

> question, I changed the test to this:

>

> function times2BitShifting(i) {

> var x = i << 1;

> }

>

> function times2RegularMath(i) {

> var x = 2 * i;

> }

>

> Again, i goes from 0 to 50000. Across all browsers, the two take

> essentially the same amount of time. I sometimes just get a 1 ms

> difference in favor of bit-shifting.

>

> Doubling w/ bit-shifting: 31

> Doubling w/ regular math: 32

>

> So is this a fair enough comparison?

earlier, and this pretty much confirms what I expected.

> Using bitwise operators seems to have no performance penalty, and in

I wasn't expecting to see a performance penalty. My point is that

> cases where it's actually useful (e.g. powers of 2), it's significantly

> [in a statistical sense] faster than regular math.

JavaScript isn't C, and micro-optimizations using bit shifts won't bring

any real advantage over normal arithmetic operations. (They're not very

helpful in C anymore either, because modern compilers are all about

optimization, and can do this sort of thing in their sleep.) It won't

make much of a difference whether you write "i << 10" or "i * 1024".

In your specific case, the performance gain is real, and apparently it's

mostly due to avoiding the method call (unless you wrap the bit shifting

it in a function, of course).

When I'm not in a tight loop, I tend to go for the most readable

implementation, even if it means using objects and properties instead of

bit fields.

cheers,

stefan