Bitwise operators are faster. Avoid these micro-optimizations
TL;DR: Don't use bitwise operators unless your business model is bitwise logic.
...
For further actions, you may consider blocking this person and/or reporting abuse
You can use the JS bitwise operator "OR" once -->
var x = y | 0this is much more efficient for computation, it do exactly as the Math.floor() function except you don't have to go trough the "Math" object and so on... (it is used in asm.js)why?
Please tell me your reasons to use the operator instead of the more declarative Math.foor ?
Do you have strong evidence this is really necessary ?
Yes because formerly it doesn't have to access the Math object to perform the operation and it is used like this not humanly though but in evidence in asm.js... both are correct, I mean one is best for readability and one is just a "trick" to force the variable being coerced into an integer, mostly interesting Low-Level-JavaScript (LLJS) explain that it is best suited like this for code that should be optimized in terms of entire number.
Relevant question is the same: Why it should be optimized?
Because computation on CPU can be slow...
I had a pixel art project, which enable one to draw on images and it does all the color blending computation in JS, which written in ASM.JS style is as much fast as it can be in webassembly, as I don't understand how I could make it work faster in WebGL...
ok. there are a few cases were you need to optimize the code.
There the 'Exceptions' in the article.
Most code does not need these optimizations
Since JavaScript Numbers are double-precision floating-point values, it shouldn't even support bitwise operators. It leads to mathematical nonsense such as
y | 0not necessarily equallingy, and likewise~~ynot necessarily equallingy.Indeed
This is also an example of Javascript magic conversions
Code Smell 69 - Big Bang (JavaScript Ridiculous Castings)
Maxi Contieri γ» May 4 '21 γ» 2 min read
Numbers aren't double-precision floating-point values when one explicitely and systematically tells the compiler
| 0hey here is a integer(x | 0)>>>0hey here is the same but positive, instead if our number is bigger than the maximum value of a 32 bits Unsigned integer, using>>>0force the compiler to use, excuse me, "no doubles" for it. (in certain case ^^)JavaScript's Number type is a IEEE 754 double-precision floating-point. developer.mozilla.org/en-US/docs/W...
JavaScript's bitwise operators on floating point Numbers coerces it to a 32bit integer (with a call to ToInt32) and then applies the bitwise op to that integer. In this way, bitwise ops on a floating-point type is pure nonsense. The op isn't being used for the actual logical use of the bitwise op. It is being used to gain access to an internal side-effect, and an internal type not otherwise exposed to the JS programmer.
That's not what the asmjs.org/ project did (from Mozilla), it wasn't non-sense at all, and all of this enabled porting C/C++ algorithms into JavaScript through Emscripten. Look, no, it is not nonsense, it is a missleading conception to think JS code isn't optimized within the JavaScript Engine. You hadn't being forced to use ASM.JS code alike for performance my friend, you should having been seen the results.
Not sure what you mean by "not what asmjs.org did". Numbers in JS are according to the JS spec, floating-point. Period. There is a BigInt type but that isn't involved in any way when applying bitwise ops to Numbers. If you are referring to what happens when one compiles C to JS, then whatever JS is produced isn't intended for human readability. The JS is essentially acting as a sort of machine code in that instance, and shouldn't be used as a baseline for writing JS that is intended for human readability.
Math.flooris not the same as~~-Math.truncis the equivalentHow to Find the Stinky Parts of Your Code ? shiva vashikaran mantra for love