Closed SukkaW closed 6 months ago
The b4a is there to make it run in the browser, overhead is negligible, and prop even optimised out by v8
The b4a is there to make it run in the browser, overhead is negligible, and prop even optimised out by v8
@mafintosh Sure, that makes sense.
My original plan was to entirely transition from Buffer
to Uint8Array
as a preliminary step towards resolving the issue #157. This would begin with unifying Buffer
usage followed by subsequent PRs focusing on migrating away from Buffer
.
Maybe I should open a PR to migrate to Uint8Array
directly, what do you think?
The PR reduces some
b4a
usages:b4a.alloc
b4a.alloc
is just an alias ofBuffer.alloc
, see https://github.com/holepunchto/b4a/blob/5a6b328df1817977351208e1991b1fdfb4bfa529/index.js#L9-#L11b4a.concat
b4a.concat
is just an alias ofBuffer.concat
, see https://github.com/holepunchto/b4a/blob/5a6b328df1817977351208e1991b1fdfb4bfa529/index.js#L29-L31b4a.from
b4a.from
is just an alias ofBuffer.from
, see https://github.com/holepunchto/b4a/blob/5a6b328df1817977351208e1991b1fdfb4bfa529/index.js#L45-L47b4a.byteLength
b4a.byteLength
is just an alias ofBuffer.byteLength
, see https://github.com/holepunchto/b4a/blob/5a6b328df1817977351208e1991b1fdfb4bfa529/index.js#L21By replacing those
b4a
usage with Node.js built-inBuffer
, the PR improves performance (as those alias methods would create extra stacks), and makes it easier to transition to the Uint8Array in future PRs.The unit tests still pass after the changes.