Tests are done without checking the results.
Pokute opened this issue · 5 comments
The results are practically invalid since the tests don't actually care about the results. This means that javascript engines can and will optimise away critical code.
*************** Map performance check ***************
js map: 15.636ms
for loop: 8.461ms
for each: 17.376ms
lodash map: 18.545ms
*************** Map performance check with result check ***************
js map: 6.106ms
sum: 49886314
for loop: 22.985ms
sum: 49886314
for each: 7.250ms
sum: 49886314
lodash map: 27.305ms
sum: 49886314
The latter case is where I just console.log the sum of commentCounts after each run and outside the timing blocks. This completely turns the results around.
@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
@Pokute
feel free to cheeckout this branch - https://github.com/dg92/Performance-Analysis-JS/tree/feature/ramda-gc-cache
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.
@dg92
I strongly suggest you watch the following video on profiling / optimisations:
LXJS 2013 - Vyacheslav Egorov - Performance and benchmarking