Benchmark against level

[vweevers]

Compare:

• level@7 against classic-level. To test the native part (now using encoding options instead of *asBuffer). Not expecting a change here.
• level-mem + subleveldown against memory-level + sublevels, with json encoding. To test the JS part. Expecting a slight improvement here, though it might only surface in real-world apps (with GC pressure) rather than a synthetic benchmark.
• Batching on level-mem against memory-level, as it removes two (or three, with sublevels) iterations of the batch array.

A quick benchmark is enough (of reads and writes). It's just to check that performance is equal or better.

[vweevers]

puts on level-mem + subleveldown versus memory-level + sublevels, with json encoding. Win.

puts on level-mem versus memory-level versus memory-level using strings internally. Double win.

[vweevers]

iterator.next() on level-mem versus memory-level, using json and utf8 valueEncodings. No difference (because the main cost is setImmediate).

[vweevers]

iterator.next() on level-mem versus iterator.nextv(1000) on memory-level. Not a fair benchmark, but the new nextv() API is an obvious win.

[vweevers]

iterator.next() on level versus iterator.next() on classic-level. Slower. I reckon that's because I changed the structure of the cache (in short: [entry, entry, ..] instead of [key, value, key, value, ..]) which should make nextv() faster. That'll be difficult to compare fairly.

[vweevers]

Batch puts on level-mem versus memory-level. Win.

[vweevers]

Gets on level-mem versus memory-level. Win.

However, memory-level is slower when using a binary valueEncoding. That warrants a closer look.

[vweevers]

However, memory-level is slower when using a binary valueEncoding. That warrants a closer look.

It's not due to binary. Happens on any encoding when this code path is triggered:

abstract-level/abstract-level.js

Lines 299 to 301 in d711af3

	if (options.keyEncoding !== keyFormat || options.valueEncoding !== valueFormat) {
	options = { ...options, keyEncoding: keyFormat, valueEncoding: valueFormat }
	}

V8 has a performance issue with the spread operator when properties are not present. The following "fixes" it:

options.keyEncoding = keyFormat
options.valueEncoding = valueFormat
options = { ...options, keyEncoding: keyFormat, valueEncoding: valueFormat }

As does using Object.assign() instead of spread:

Could switch to Object.assign() but I do still generally prefer the spread operator, for being idiomatic (not being vulnerable to prototype pollution could be another argument but I don't see how that would matter here).