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

Re: Save and restore jslint settings

Expand Messages
  • aseem.kishore@ymail.com
    I agree with the general goal here, but I would like to request functional scope instead of a stack. This is analogous to how use strict works as well. So it
    Message 1 of 13 , Sep 2, 2009
    • 0 Attachment
      I agree with the general goal here, but I would like to request functional scope instead of a stack. This is analogous to how "use strict" works as well.

      So it would be great if I could disallow bitwise operators in general, and allow it inside of an optimized mathematical function. What do you think of this?
    • christian.wirkus
      Off the topic: Are you sure bitwise operators optimize anything in Javascript? Javascript isn t C, and the data type number is 64 bit float, not integer.
      Message 2 of 13 , Sep 2, 2009
      • 0 Attachment
        Off the topic:
        Are you sure bitwise operators optimize anything in Javascript?
        Javascript isn't C, and the data type number is 64 bit float, not integer.


        --- In jslint_com@yahoogroups.com, "aseem.kishore@..." <aseem.kishore@...> wrote:
        >
        > I agree with the general goal here, but I would like to request functional scope instead of a stack. This is analogous to how "use strict" works as well.
        >
        > So it would be great if I could disallow bitwise operators in general, and allow it inside of an optimized mathematical function. What do you think of this?
        >
      • aseem.kishore@ymail.com
        Fair points. I use bitwise operators in two cases currently: - For constructing Morton numbers (mapping two dimensions to one). From Wikipedia: [...] a Morton
        Message 3 of 13 , Sep 2, 2009
        • 0 Attachment
          Fair points. I use bitwise operators in two cases currently:

          - For constructing Morton numbers (mapping two dimensions to one). From Wikipedia: "[...] a Morton number is a single integer value constructed by interleaving the bits or digits of one or more source numbers." http://en.wikipedia.org/wiki/Morton_number_(number_theory)

          - For addressing Virtual Earth tiles (which uses a quadtree). From MSDN: "To convert tile coordinates into a quadkey, the bits of the Y and X coordinates are interleaved, and the result is interpreted as a base-4 number [...]" http://msdn.microsoft.com/en-us/library/bb259689.aspx

          In both cases, the functions are only called with integer numbers. You're right that in Javascript, all numbers are technically doubles, but yet using the bitwise operators seems to work perfectly well. I'm not sure.

          I'm also not sure about whether that indeed optimizes anything. I haven't done profiling comparisons; I'm just reusing well-known algorithms.

          --- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@...> wrote:
          >
          > Off the topic:
          > Are you sure bitwise operators optimize anything in Javascript?
          > Javascript isn't C, and the data type number is 64 bit float, not integer.
          >
        • Paul Novitski
          ... At 9/2/2009 10:24 AM, aseem.kishore@ymail.com wrote: ... Christian, my guess is that the reasoning behind your comment is an assumption that Aseem would
          Message 4 of 13 , Sep 2, 2009
          • 0 Attachment
            >--- 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
          • pauanyu
            ... I had the same idea, but with different syntax: use strict ; var prop, foo; /*options forin: true */ for (prop in foo) { foo[prop] = foo ; } /*end
            Message 5 of 13 , Sep 2, 2009
            • 0 Attachment
              --- In jslint_com@yahoogroups.com, "woomla" <woomla@...> wrote:
              >
              > Every know and then I want to change a /*jslint*/ setting for a particular statement. After the statement I want to restore the setting to its previous state. It would be nice if I can restore the setting without knowing its previous state/value (i.e. indent).
              >
              > A solution would be something to push the options and afterwards pop the options:
              >
              > "use strict";
              > var prop, foo;
              >
              > /*pushoptions*/
              > /*jslint forin:true*/
              > for (prop in foo) {
              > foo[prop] = "foo";
              > }
              > /*jslint forin:false*/
              > /*popoptions*/
              >
              >
              > I've implemented this in my pspad plugin and it works great. I would love to see it in the official script though.
              >

              I had the same idea, but with different syntax:

              "use strict";
              var prop, foo;

              /*options forin: true */
              for (prop in foo) {
              foo[prop] = "foo";
              }
              /*end options */
            • christian.wirkus
              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
              Message 6 of 13 , Sep 3, 2009
              • 0 Attachment
                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
                >
              • aseem.kishore@ymail.com
                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
                Message 7 of 13 , Sep 4, 2009
                • 0 Attachment
                  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
                  > >
                  >
                • Stefan Weiss
                  ... 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
                  Message 8 of 13 , Sep 4, 2009
                  • 0 Attachment
                    On 04/09/09 18:10, aseem.kishore@... 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
                  • 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 9 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]
                    • aseem.kishore@ymail.com
                      ... 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
                      Message 10 of 13 , Sep 4, 2009
                      • 0 Attachment
                        --- In jslint_com@yahoogroups.com, Stefan Weiss <weiss@...> wrote:
                        >
                        > On 04/09/09 18:10, aseem.kishore@... 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
                        >

                        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? 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.

                        Aseem
                      • Arthur Blake
                        One would think that modern JIT compiler implementations of JS would make this whole discussion moot... On Fri, Sep 4, 2009 at 4:01 PM,
                        Message 11 of 13 , Sep 4, 2009
                        • 0 Attachment
                          One would think that modern JIT compiler implementations of JS would
                          make this whole discussion moot...

                          On Fri, Sep 4, 2009 at 4:01 PM,
                          aseem.kishore@...<aseem.kishore@...> wrote:
                          >
                          >
                          > --- In jslint_com@yahoogroups.com, Stefan Weiss <weiss@...> wrote:
                          >
                          >>
                          >> On 04/09/09 18:10, aseem.kishore@... 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
                          >>
                          >
                          > 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? 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.
                          >
                          > Aseem
                          >
                          >
                        • 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 12 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.