-
-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Breaking: bump abstract-level
to 2.0.0
#52
Conversation
abstract-level
to 2.0.0abstract-level
to 2.0.0
abstract-level
to 2.0.0abstract-level
to 2.0.0
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. |
Category: none
Category: change
Category: removal
Category: change
Category: removal
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 Category: fix
This is a new optional feature in `abstract-level` 2.0.0. Category: addition
Too much hassle. If you use FreeBSD and would like to see this restored then please reach out. It will require a commitment to help with maintenance and any issues that may arise. Category: removal
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. Category: change
Category: fix
Category: none
Done. I squashed some commits, tweaked descriptions. This push contains no code changes besides a typo and changing Considering the amount of time passed since I opened this PR, I want to revisit CI, e.g. to drop Node.js 16 and bump the |
Canceling CI because macos jobs are stuck in the queue for 10+ minutes. |
TODO:
get()
synchronously (Epic: implicit and explicit snapshots community#118)signal
option 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.