Boolean vs Int in Javascript

后端 未结 4 1992
独厮守ぢ
独厮守ぢ 2020-12-31 03:05

I always assumed that booleans were more efficient than ints at storing an on/off value - considering that\'s their reason for existence. I recently decided to check if this

相关标签:
4条回答
  • 2020-12-31 03:35

    For me the choice would be based on API usage. Always return that which is most useful. If I use secondary code, I'd favor methods that return booleans. This probably makes the code ready to be chained. The alternative is to provide overloaded methods.

    0 讨论(0)
  • 2020-12-31 03:37

    your test was a bit off due to the definition of "function" and "var" and the call for the function. The cost to define function and variables and calling them will differ from engine to engine. I modified your tests, try to re-run with your browsers (note that IE was off because the first run was weird but consecutive runs were as expected where bool is fastest): http://jsperf.com/bool-vs-int-2/4

    0 讨论(0)
  • 2020-12-31 03:37

    I don't know but in the second test it does
    if(a) bluh();
    vs
    if(c == 1) bluh();

    maybe c==1 is faster because you're comparing a value with one with the same type
    but if you do if(a) then js need to check if the value evaluates to true, not just if it is true...

    That could be the reason...

    Maybe we need to test
    if(c==1)
    vs
    if(a===true) with three =

    0 讨论(0)
  • 2020-12-31 03:49

    Disclaimer, I can only speak for Firefox, but I guess Chrome is similar.

    First example (http://jsperf.com/bool-vs-int):

    1. The Not operation JägerMonkey (Spidmonkey's JavaScript methodjit) inlines the check for boolean first and then just xors, which is really fast (We don't know the type of a/b, so we need to check the type). The second check is for int, so if a/b would be a int this would be a little bit slower. Code

    2. The Subtract operation. We again don't know the type of c/d. And again you are lucky we are going to assume ints and inline that first. But because in JavaScript number operations are specified to be IEEE 754 doubles, we need to check for overflow. So the only difference is "sub" and a "conditional jump" on overflow vs. plain xor in case 1. Code

    Second example: (I am not 100% sure about these, because I never really looked at this code before)

    1. and 3. The If. We inline a check for boolean, all other cases end up calling a function converting the value to a boolean. Code

    2. The Compare and If. This one is a really complex case from the implementation point of view, because it was really important to optimize equality operations. So I think I found the right code, that seems to suggest we first check for double and then for integers. And because we know that the result of a compare is always a boolean, we can optimize the if statement. Code

    Followup I dumped the generated machine code, so if you are still interested, here you go.

    Overall this is just a piece in a bigger picture. If we knew what kind of type the variables had and knew that the subtraction won't overflow then we could make all these cases about equally fast. These efforts are being made with IonMonkey or v8's Crankshaft. This means you should avoid optimizing based of this information, because:

    1. it's already pretty fast
    2. the engine developers take care of optimizing it for you
    3. it will be even faster in the future.
    0 讨论(0)
提交回复
热议问题