Add browser support to benchmark suite

[nrabinowitz]

I'm guessing browser benchmarks are more relevant to many consumers than Node benchmarks. This adds browser support to the benchmark suite - yarn benchmark-browser opens a new browser window with the benchmark suite:

• Moves benchmark suite from test to benchmark
• Adds a separate browser runner that prints results to the page with nice formatting

The results are surprisingly comparable, and in some cases the browser appears faster (Chrome 69 vs Node 8.12):

Browser

h3IsValid x 3,955,609 ops/sec ±1.72% (60 runs sampled)
geoToH3 x 354,704 ops/sec ±1.26% (60 runs sampled)
h3ToGeo x 1,021,646 ops/sec ±0.69% (63 runs sampled)
h3ToGeoBoundary x 285,974 ops/sec ±0.69% (63 runs sampled)
kRing x 156,840 ops/sec ±0.76% (62 runs sampled)
polyfill x 13,606 ops/sec ±1.13% (62 runs sampled)
h3SetToMultiPolygon x 432 ops/sec ±0.35% (62 runs sampled)
compact x 928 ops/sec ±0.32% (63 runs sampled)
uncompact x 563 ops/sec ±0.54% (62 runs sampled)
h3IndexesAreNeighbors x 1,034,136 ops/sec ±0.56% (61 runs sampled)
getH3UnidirectionalEdge x 457,568 ops/sec ±0.62% (64 runs sampled)
getOriginH3IndexFromUnidirectionalEdge x 985,389 ops/sec ±0.62% (62 runs sampled)
getDestinationH3IndexFromUnidirectionalEdge x 896,725 ops/sec ±0.57% (63 runs sampled)
h3UnidirectionalEdgeIsValid x 3,595,424 ops/sec ±0.93% (62 runs sampled)

Node

h3IsValid x 3,755,913 ops/sec ±0.90% (89 runs sampled)
geoToH3 x 388,048 ops/sec ±0.86% (90 runs sampled)
h3ToGeo x 1,104,667 ops/sec ±0.61% (86 runs sampled)
h3ToGeoBoundary x 306,485 ops/sec ±0.51% (89 runs sampled)
kRing x 159,300 ops/sec ±0.89% (89 runs sampled)
polyfill x 14,602 ops/sec ±0.79% (88 runs sampled)
h3SetToMultiPolygon x 474 ops/sec ±0.71% (87 runs sampled)
compact x 1,205 ops/sec ±0.59% (88 runs sampled)
uncompact x 575 ops/sec ±0.79% (85 runs sampled)
h3IndexesAreNeighbors x 1,119,164 ops/sec ±0.65% (87 runs sampled)
getH3UnidirectionalEdge x 501,265 ops/sec ±0.54% (90 runs sampled)
getOriginH3IndexFromUnidirectionalEdge x 1,043,195 ops/sec ±0.67% (89 runs sampled)
getDestinationH3IndexFromUnidirectionalEdge x 908,975 ops/sec ±0.53% (90 runs sampled)
h3UnidirectionalEdgeIsValid x 3,280,875 ops/sec ±0.67% (90 runs sampled)

[coveralls]

Pull Request Test Coverage Report for Build 47

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 45:	0.0%
Covered Lines:	350
Relevant Lines:	350

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 46

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 45:	0.0%
Covered Lines:	350
Relevant Lines:	350

---

💛 - Coveralls

[dfellis]

This is awesome! :) But the results aren't as surprising to me, both use V8 under the hood, both are using emscripten-transpiled versions of H3 (since Node's C/C++ binding story has been so wild and bad over the various major versions), and no browser DOM-related pieces are in use.

I'd probably chalk up perf differences to changes in V8's JIT.

[isaachier]

Awesome stuff!