-
-
Notifications
You must be signed in to change notification settings - Fork 16
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
Dump Buffer for TypedArrays (for compactness and efficiency) #90
Comments
Some nuance: buffer is 147 bytes minified and gzipped. Calling it "massive" isn't fair, especially considering the interoperability that it enables. That said, I understand the need to shave off bytes wherever possible. Unfortunately, the level ecosystem does use buffer heavily. The dozens of modules probably only use a small part of buffer's API, that's true, but switching to typed arrays (or restricting ourselves to UInt8Array's API) is nevertheless a huge breaking change and a huge effort. |
I'd like to keep this open as a reminder. And to allow folks to chime in; I don't want to give the signal "it's never gonna happen". |
Ah okay!
Well it would be really nice to use these existing lower level APIs vs
buffer.
Our apps need to work in countries where the internet connection is poor
even with CDNs, so every byte over the wire counts for performance and
experience.
I love the level APIs and philosophy (aside from a few little things) and
would love to see a move to a lighter version.
…On Wed, May 20, 2020 at 7:40 AM Vincent Weevers ***@***.***> wrote:
I'd like to keep this open as a reminder. And to allow folks to chime in;
I don't want to give the signal "it's never gonna happen".
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#90 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACK2CXSVQ7OT6B6W3TSZSSDRSO6T3ANCNFSM4M5DWZAA>
.
|
I'm not even sure you'd save anything in the long run - Buffer gives extensive encoder support - that would have to be moved in level* if its not on the Buffer. If its something you're passionate about, I'd recommend forking abstract-leveldown and try passing a Buffer prototype through to its constructor, which would be used in-place of require'ing the existing Buffer ponyfill. doing it this way is the least painful approach I can think of - but give the user the option to pass a custom cut-down prototype explicit for their needs and stack. I'm more concerned with multiple Buffer ponyfills more than anything - I'm pretty sure current build (webpack) is bundling another Buffer polyfill. Also better support for Uint8Array would be nice: in my custom encoder I have to wrap a Uint8Array in a Buffer else its re-encoded, for some reason. |
The answer for that is to not use const compose = require('level-compose')
const factory = compose(leveldown, levelup)
const db = factory('./db') Which is to say, those folks won't get encodings, unless we write an alternative to WIP list of tasks to make buffer optional (feel free to edit):
|
Covered by #102 and https://github.com/Level/transcoder. It will be possible to use either Uint8Array, Buffer, or both, and to exclude the |
Hi all,
Coming from the browser focused world, I see many of the Level libraries don't really use a ton of Buffer facility, and considering Buffer's can be easily fitted (and are just a view to) typed arrays, why not just dump the massive Buffer library altogether.
This would make Level a much leaner construction for browser based or p2p apps like mine, and may even make processing at a micro level faster.
Thoughts?
The text was updated successfully, but these errors were encountered: