Your first code snippet could be greatly simplified if you used the PROPER code... and proper would mean you don't need your "sentinel value" whatsoever. It's called "break".

var found = false;
for (var item of items) {
if (item === value) {
found = true;
break;
}
}

Or if you need it for legacy browsers:

for (var i = 0, found = false, iLen = items.length; i < iLen; i++) {
if (item[i] === value) {
found = true;
break;
}
}

It also works with while if you insist. break if will take you out of ALL loop-level operation, just as continue will skip the rest of the current code inside the loop.

Also a good illustration of why VAR is superior to LET and CONST. On top of less memory thrashing, we can define it on the loop and it still exists after since we're not "over-scoping for nothing".

Your second point about busiest loops is utter gibberish. Either way it's 600 iterations, so I'm really not sure where you get 600 or 505. Makes me think you don't understand what FOR does.

The rest of your points lacking examples seem even more nonsensical.

Whist there are machine language level situations where shifts or additions can be faster than multiply, you're talking out your backside on this "Strength Reduction" thing. I don't know if you're just regurgitating what someone else said, or if you really don't understand that one operation might be faster than many.

Reducing array dimensions would depend on the data, so that's really not a meaningful blanket statement.

Your caching is also utterly banjaxed because JavaScript arrays are slow. Likely because they aren't ACTUALLY arrays under the hood, they're pointered lists. Likewise objects behave as pointered lists requiring long comparisons, which means a lookup can in fact take many, MANY times longer than just returning the result.

Hence your caching lookup likely takes many, MANY times longer than just performing the addition... or even complete long calculations... or even many lines of actual logic.

Now, there are cases where caching can be faster, but you need to profile your code before you start pulling these types of goofy memory wasting CPU load inducing stunts.

Laughably a lot of what you're saying would make perfect sense in a compiled language... but in an interpreted language you're not making a lick of sense whatsoever.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store