Breaking: bump abstract-level to 2.0.0
#52
Conversation
vweevers
changed the title
abstract-level to 2.0.0abstract-level to 2.0.0
vweevers
changed the title
abstract-level to 2.0.0abstract-level to 2.0.0
And `LEVEL_NOT_FOUND` with `undefined`. Passes the abstract test suite. Most other tests are commented out. The `iterator.next()` method required a small change: previously we had the callback signature `(err, entries, finished)` where "finished" meant "reached the end of the data". Now we have a promise for only `entries`. So an extra `next()` call (end-to-end) is now needed to know that the end was reached.
Has a tiny performance cost, which I negated by optimizing the passing of options from JS to C++. The end result is faster than before. However, I didn't check if it blocks the event loop for a significant amount of time. Benchmarking concurrent gets might answer that, later. Ref Level/community#118.
Too much hassle.
Instead of copying abstract-level docs and then tweaking it for classic-level (on every release, which was a bit of a pain) the README now only describes the differences.
|
Hey, when do you plan to merge/release v2? Looking forward to it, thanks! |
|
@vweevers would you like some help with benchmarking? |
|
Help is always welcome, thank you! Though FYI, that's not why I haven't released this yet. Just haven't had the time, and I don't consider benchmarks to be a blocker (because e.g. promises are unlikely to make a big difference here) so I planned to just skip them when I got to it. The only thing that slightly worries me is that |
|
@vweevers no pressure meant or implied. I depend on level packages through quadstore and I'd be happy to help an upstream dependency if I can find the time. Also, my experience with promise-based iteration is exactly the opposite; so far I've always found it to make a rather big difference, particularly with asynchronous sources capable of reading and returning multiple items in batches and particularly when structuring chains of iterators. That said, I also recognize that I'm not as experienced as you are. I'll have a look next week! |
|
I'm not that experienced with promises themselves, I meant more that disk and the C<>JS barrier are the bigger bottlenecks here. But it's always good to challenge such assumptions. You're probably right that there's an overhead to e.g. async iterators. For people that were already using promises, I do hope that abstract-level v2 and classic-level v2 are faster because they no longer have to translate callbacks into promises, allowing V8 to optimize it. |
TODO:
get()synchronously (Tracking issue: implicit and explicit snapshots community#118)signaloption on iteratorsget()concurrently, to see if synchronous snapshot blocks event loopiterator(), to compare callbacks vs promisesput(), to compare callbacks vs promisesTo be rebased (not fully squashed) before merge.