backbone.marionette icon indicating copy to clipboard operation
backbone.marionette copied to clipboard

Use Benchmark.js to measure performance

Open rafde opened this issue 7 years ago • 5 comments

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

rafde avatar Sep 15 '16 03:09 rafde

Very nice idea! :+1:

JSteunou avatar Sep 15 '16 08:09 JSteunou

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

scott-w avatar Sep 17 '16 09:09 scott-w

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).

rafde avatar Sep 27 '16 06:09 rafde

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.

scott-w avatar Sep 27 '16 15:09 scott-w

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

rafde avatar Sep 29 '16 06:09 rafde