Variety of speed ups for parsing mappings

[fitzgen]

This builds on top of #185

This is a variety of speed ups to parsing mappings. Most notable is rolling our own sorting in JS. See

source-map/lib/source-map/quick-sort.js

Lines 12 to 20 in a0f0ff8

	// It turns out that some (most?) JavaScript engines don't self-host
	// `Array.prototype.sort`. This makes sense because C++ will likely remain
	// faster than JS when doing raw CPU-intensive sorting. However, when using a
	// custom comparator function, calling back and forth between the VM's C++ and
	// JIT'd JS is rather slow *and* loses JIT type information, resulting in
	// worse generated code for the comparator function than would be optimal. In
	// fact, when sorting with a comparator, these costs outweigh the benefits of
	// sorting in C++. By using our own JS-implemented Quick Sort (below), we get
	// a ~3500ms mean speed-up in `bench/bench.html`.

for a description of why that is.

r? @ejpbruel

[ejpbruel]

This seems like it would be race condition prone, since the results are timing dependent. Is there a better way to warm up the JIT, that does not suffer from timing effects?

[fitzgen]

Unfortunately, because each parse takes so long, we can't just run it n times before measuring, and I don't think there is a better way.

[ejpbruel]

Patch looks good to me. r+

These are great improvements. It's quite fun how we're scraping the barrel of JS performance with this library :-)