Remove fast-future

[vweevers]

We can remove fast-future, because the iterator's cache mechanism already prevents event loop starvation (as mentioned by @peakji in #327 (comment)) - unless you have single-byte keys and values. To handle that rare case we can move the internal counter of fast-future to the C++ of leveldown: it eithers stop iterating when it hits the highWaterMark (in bytes) or when the cache is 1000 elements long.

[peakji]

I was thinking about the exact same thing! 😂

[peakji]

After reading the iterator code again, I think we can further optimize the cache mechanism:

1. Do not reverse the cache array in C++ land (which might produce "holes" and slow things down?).
2. Instead of calling .pop() on the cache array, we could just use an offset to access elements and leave the cache array immutable.

Maybe this will give us a performance gain?

[vweevers]

Lemme try to write a benchmark, so we can try those ideas. I'm thinking this benchmark will first insert a small data set (say 10K records), trigger a manual compaction, read once from start to end as a warmup, and then repeatedly read it from start to end.

[peakji]

Shall we merge this PR so that I can rebase #640?

[vweevers]

Shall we merge this PR so that I can rebase #640?

I wanted to benchmark this first, but seeing as I'm not getting around to that, maybe yeah

[peakji]

I wanted to benchmark this first, but seeing as I'm not getting around to that, maybe yeah

I've benchmarked these branches with an old script: https://gist.github.com/peakji/0fd6c1529951767697480e708806ae33#file-benchmark-js

After running the script for multiple times, result shows the performance of remove-fast-future is almost identical to master (as expected), but immutable-cache-array is obviously slower.

#	master	remove-fast-future	immutable-cache-array
SUM	36549118185	36484380542	38067624251
CNT	10000	10000	10000
AVG	3654911.8185	3648438.0542	3806762.4251
MIN	932207	905891	911134
MAX	9835033	9715972	12222045

[peakji]

I think its safe to merge #638, and reject #640.

[vweevers]

@peakji I expected remove-fast-future to be very slighty faster because it allocates less functions.

As a next step, I think Level/community#70 is worth exploring.

[peakji]

I expected remove-fast-future to be very slighty faster because it allocates less functions.

Actually it is 0.17% faster! 😄

As a next step, I think Level/community#70 is worth exploring.

👍 Shall we tag a new release first (maybe including #642)?

[vweevers]

5.1.1