Loading ...
Sorry, an error occurred while loading the content.

Re: [jslint] Re: Save and restore jslint settings

Expand Messages
  • Aseem Kishore
    Fair enough. If you can think of a better way to test this, let me know. I m all for finding a more efficient alternative. =) Aseem ... [Non-text portions of
    Message 1 of 13 , Sep 4, 2009
    • 0 Attachment
      Fair enough. If you can think of a better way to test this, let me know. I'm
      all for finding a more efficient alternative. =)
      Aseem

      On Fri, Sep 4, 2009 at 9:36 AM, Stefan Weiss <weiss@...> wrote:

      >
      >
      > On 04/09/09 18:10, aseem.kishore@... <aseem.kishore%40ymail.com>wrote:
      > > 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));
      > > }
      >
      > 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.
      >
      > cheers,
      > stefan
      >
      >


      [Non-text portions of this message have been removed]
    • Stefan Weiss
      ... Much better, thank you. I didn t have the time to cook up a test myself earlier, and this pretty much confirms what I expected. ... I wasn t expecting to
      Message 2 of 13 , Sep 4, 2009
      • 0 Attachment
        On 04/09/09 22:01, aseem.kishore@... wrote:
        > --- In jslint_com@yahoogroups.com, Stefan Weiss <weiss@...> wrote:
        >> 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?

        Much better, thank you. I didn't have the time to cook up a test myself
        earlier, and this pretty much confirms what I expected.

        > Using bitwise operators seems to have no performance penalty, and in
        > cases where it's actually useful (e.g. powers of 2), it's significantly
        > [in a statistical sense] faster than regular math.

        I wasn't expecting to see a performance penalty. My point is that
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.