Tests are done without checking the results. about performance-analysis-js HOT 5 OPEN

This is more of a case of optimisation or dead code elimination.

   let foo = 10;
   foo = /* InsanelyComplicatedAndIntensiveCalculationWithNoSideEffects. */
   foo = 20;

A good JS engine will completely skip the first two assignments.

The fact that results change so dramatically from code that's outside the timing block is a telltale sign that some dead code elimination is taking place. But this test case's purpose is not to measure dead code elimination. It's purpose is to inform which method is the fastest for users, who use the code in real world situations where they do care about and do use the end result of map operation and thus dead code elimination will not occur.

from performance-analysis-js.

@dg92
I strongly suggest you watch the following video on profiling / optimisations:
LXJS 2013 - Vyacheslav Egorov - Performance and benchmarking

from performance-analysis-js.

@Pokute if you spend time reading the note in readme then you might not have to create an issue
Note
These results are computed using Node V8 v5.8.283.41
These result does not consider the JIT, inline caching, hidden classes, deoptimizations, garbage collection, pretenuring etc.
Result may vary as per env's.

Hope that answer the variation

from performance-analysis-js.

@Pokute
feel free to cheeckout this branch - https://github.com/dg92/Performance-Analysis-JS/tree/feature/ramda-gc-cache

from performance-analysis-js.

@Pokute sure thanks for sharing.

Open to accept the MR if you feel it will bring a positive change.

from performance-analysis-js.