Investigate storing vertex coords in Node for performance

[mourner]

Ref: mapbox/earcut.hpp#10. We should try this and benchmark. cc @jfirebaugh

[mourner]

@jfirebaugh pushed in node-vertex branch. The benchmark results are weird... On Node 0.12, it makes earcut faster on the very simple shapes but slower (up to 20%) on bigger shapes:

# node-vertex
typical OSM building (15 vertices): x 736,335 ops/sec ±0.67% (100 runs sampled)
dude shape (94 vertices): x 35,703 ops/sec ±0.81% (97 runs sampled)
dude shape with holes (104 vertices): x 22,036 ops/sec ±0.63% (99 runs sampled)
complex OSM water (2523 vertices): x 546 ops/sec ±1.23% (95 runs sampled)

# master
typical OSM building (15 vertices): x 660,687 ops/sec ±0.54% (99 runs sampled)
dude shape (94 vertices): x 36,895 ops/sec ±0.41% (100 runs sampled)
dude shape with holes (104 vertices): x 28,153 ops/sec ±0.81% (98 runs sampled)
complex OSM water (2523 vertices): x 618 ops/sec ±0.51% (98 runs sampled)

I have no idea why. Perhaps cache locality is better in master, because the vertex data is one array?

[mourner]

Want to revisit this after #40, the perf results will probably be different.

[mourner]

This looks much better after #40, just as I thought:

#after
typical OSM building (15 vertices): x 690,545 ops/sec ±0.79% (97 runs sampled)
dude shape (94 vertices): x 34,725 ops/sec ±0.96% (95 runs sampled)
dude shape with holes (104 vertices): x 28,232 ops/sec ±0.95% (98 runs sampled)
complex OSM water (2523 vertices): x 518 ops/sec ±0.92% (93 runs sampled)

#before
typical OSM building (15 vertices): x 547,085 ops/sec ±1.15% (90 runs sampled)
dude shape (94 vertices): x 32,865 ops/sec ±0.94% (94 runs sampled)
dude shape with holes (104 vertices): x 25,811 ops/sec ±1.05% (96 runs sampled)
complex OSM water (2523 vertices): x 532 ops/sec ±4.07% (90 runs sampled)