Use Benchmark.js to measure performance

[rafde]

This is kind of a dup of #2267 but with a proposal to use Benchmark.js

It could/should be included in the PR checks. Although it might display false reports in performance due to thread hiccup.

With all the performance work and claims I've been doing, it'd be nice to have a way to show that I am actually making a difference with the work.

Environment

1. Marionette version: 3

[JSteunou]

Very nice idea! 👍

[scott-w]

Totally agree, I think it'll be a great addition 👍

[rafde]

https://github.com/rafde/backbone.marionette/tree/benchmark-runner
So I got it doing the benchmarking
Looking to resolve for

[SECURITY] node-uuid: crypto not usable, falling back to insecure Math.random()

Other than that, I notice some strangeness

[22:36:30] Requiring external module babel-core/register
[SECURITY] node-uuid: crypto not usable, falling back to insecure Math.random()
[22:36:34] Using gulpfile ~/Documents/repos/backbone.marionette/gulpfile.babel.js
[22:36:35] Starting 'benchmark'...
[22:36:35] Running 'collection view remove' from ~/Documents/repos/backbone.marionette/benchmark/suite/collection-view.added.benchmark.js ...
[22:36:43] Current: added (next 250) x 3,634 ops/sec ±6.05% (25 runs sampled)
[22:36:50] Latest: added (next 250) x 3,687 ops/sec ±5.47% (23 runs sampled)
[22:36:50] 'collection view remove' from ~/Documents/repos/backbone.marionette/benchmark/suite/collection-view.added.benchmark.js (passed: 2, failed: 0)
[22:36:50] Passed:
[22:36:50] 'Latest: added (next 250)' is etalon
[22:36:50] 'Current: added (next 250)' at 1.01x slower
[22:36:50] Running 'collection view remove' from ~/Documents/repos/backbone.marionette/benchmark/suite/collection-view.remove.benchmark.js ...
[22:36:57] Current: remove x 3,619,642 ops/sec ±7.62% (30 runs sampled)
[22:37:04] Latest: remove x 3,191,162 ops/sec ±15.60% (26 runs sampled)
[22:37:04] 'collection view remove' from ~/Documents/repos/backbone.marionette/benchmark/suite/collection-view.remove.benchmark.js (passed: 2, failed: 0)
[22:37:04] Passed:
[22:37:04] 'Current: remove' is etalon
[22:37:04] 'Latest: remove' at 1.13x slower
[22:37:04] Running 'collection view render' from ~/Documents/repos/backbone.marionette/benchmark/suite/collection-view.render.benchmark.js ...
[22:37:10] Current: render x 58.26 ops/sec ±3.86% (60 runs sampled)
[22:37:15] Latest: render x 48.75 ops/sec ±9.28% (54 runs sampled)
[22:37:15] 'collection view render' from ~/Documents/repos/backbone.marionette/benchmark/suite/collection-view.render.benchmark.js (passed: 2, failed: 0)
[22:37:15] Passed:
[22:37:15] 'Current: render' is etalon
[22:37:15] 'Latest: render' at 1.19x slower
[22:37:15] Finished 'benchmark' after 41 s

Where "Current" is from the lib folder and "Latest" is from src

I cherry picked my branch into another branch off master and the result is what you see above.

The results on who is slower varies a bit where sometime latest is fastest

The difference being that one uses ES2015 (src) and one is transpiled (lib)

Now I have to figure out if

1. the src is slow because Node.js 4 hasn't optimized for ES2015
2. I did something wrong
3. This is all going down a wild goose chase where carrying on would lead to false assessment.

Looking at 1 would have me transpile src in temp for benchmarking and make sure the result is close to 1.

2 seems likely (since I know me is usually 80% right all the time).

[scott-w]

I recall seeing some articles from the Chrome team saying they'd not optimised many ES2015 features yet (including let and const were slower than var) so that could explain some of it.

[rafde]

So I tested it using transpiled latest vs current and it still doesn't look right. The best perf flips between each and the slowness varies.
3 is looking likely.

My next step is to see if I can use V8 console profiling to determine if its more consistent in giving performance analysis compared to Benchmark.js