Performance-Analysis-JS

>the react-ish pseudocode probably doesn't make nearly as many allocations as a naive reading of the code might expect. Who knows, if V8 manages it to turn it into a for-loop? I don't, but after a quick googling, as of 2018, it certainly didn't: https://github.com/dg92/Performance-Analysis-JS The problem with JS is that the execution model is so nebulous, that performance advice basically boils down to - trust in Google.

There's no description of what's actually being tested but you can find it in the formulas.js file: https://github.com/dg92/Performance-analysis-es6/blob/master... Even on one of the first lines, there was already a mistake with how reduce is called: let avg = 0; console.time('js reduce'); avg = posts.reduce(p => avg+= (+p.downvotes+ +p.upvotes+ +p.commentCount)/3,0); avg = avg/posts.length; console.timeEnd('js reduce') The way he's using it makes it no different from a forEach. It should be `posts.reduce((p, accumulation) => accumulation + blah, 0)` instead. Also the timing isn't very sophisticated. Doing microbenchmarking right is basically black magic but the mistakes he's making are really basic (only running each version of the code once, not preventing dead code elimination, etc). Someone mentioned elsewhere th

I looked at https://github.com/dg92/Performance-analysis-es6/blob/master... briefly and saw that the different algorithms always run one after another. Does the first algorithm get an unfair cold cache disadvantage?