When it comes to optimization, less if often better. If you have branching it's likely that the CPU will run all branches anyway. You also want to stay in the CPU and off the memory. And bitwise operations are usually not faster in JavaScript. I probably missed the point but blame it on the stupid examples. I also think it's stupid to write dot net C# when you can write JavaScript with NodeJS :P
```
var dividers = {
2: function divideBy2 (lhs, unused) {
return lhs >> 1
},
4: function divideBy4 (lhs, unused) {
return lhs >> 2
},
undefined: function divideByNumber (lhs, rhs) {
return lhs / rhs
}
}
```
Does this actually work? I tried it out in the Chrome Debugger and it didn't work. It looks like the author is confusing it with Rusts match statement.
I have been experimenting along these lines. Not so much aiming towards what is optimised but rather what is potentially optimisable.
for instance
function callerOfAll(fns) {
if (fns.length===0) return ()=>{};
if (fns.length === 1) return fns[0];
var first = fns.shift();
var rest = callerOfAll(fns);
return ()=>{first();rest();}
}
This should take a list of functions and return a function that calls them all. An optimiser should be able to inline the function call if it notices each rest() is only ever called once. Ultimately it could turn
[a,b,c,d,e] into ()=>(a();b();c();d();e());
or even further if those functions themselves are small enough to be inlinable.
Looking at V8 IR, it doesn't seem to get there.
I have wondered about making a benchmark suite out of such tricky but logically optimisable structures to give Javascript engines something to aim for.
