Skip to content
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

fix: always return uint8arrays #39

Merged
merged 2 commits into from
Sep 28, 2022
Merged

Conversation

achingbrain
Copy link
Owner

@achingbrain achingbrain commented Sep 14, 2022

3.1.0 incorporated internal refactors to use node Buffers where possible to increase performance when allocing new byte arrays.

It then returns those Buffers but the problem is Buffer is not completely compatible with Uint8Array as some methods with the same name behave differently.

We can convert a Buffer to a Uint8Array without copying it by using the 3-arg Uint8Array constructor so we should do that to retain the performance characteristics of Buffer when allocing but the compatibility of returning vanilla Uint8Arrays at the cost of a performance hit to Uint8Arrays.allocUnsafe (see the added alloc.js benchmark).

Before:

Uint8Arrays.alloc x 1,559,446 ops/sec ±2.00% (79 runs sampled)
Uint8Arrays.allocUnsafe x 5,410,575 ops/sec ±1.11% (90 runs sampled)
new Uint8Array x 1,757,101 ops/sec ±1.85% (79 runs sampled)
Buffer.alloc x 1,691,343 ops/sec ±2.17% (79 runs sampled)
Buffer.allocUnsafe x 6,928,848 ops/sec ±1.18% (89 runs sampled)
Fastest is Buffer.allocUnsafe

After:

Uint8Arrays.alloc x 1,480,130 ops/sec ±2.64% (80 runs sampled)
Uint8Arrays.allocUnsafe x 4,425,871 ops/sec ±0.91% (91 runs sampled)
new Uint8Array x 1,723,491 ops/sec ±2.62% (75 runs sampled)
Buffer.alloc x 1,697,649 ops/sec ±2.49% (79 runs sampled)
Buffer.allocUnsafe x 6,662,341 ops/sec ±1.25% (88 runs sampled)
Fastest is Buffer.allocUnsafe

Fixes #38

3.1.0 incorporated internal refactors to use node `Buffer`s where
possible to increase performance when `alloc`ing new byte arrays.

It then returns those `Buffer`s but the problem is `Buffer` is not
completely compatible with `Uint8Array` as some methods with the
same name behave differently.

We can convert a `Buffer` to a `Uint8Array` without copying it
by using the 3-arg `Uint8Array` constructor so we should do that to
retain the performance characteristics of `Buffer` when `alloc`ing
but the compatibility of returning vanilla `Uint8Array`s.
@codecov-commenter
Copy link

codecov-commenter commented Sep 14, 2022

Codecov Report

Base: 95.38% // Head: 95.00% // Decreases project coverage by -0.38% ⚠️

Coverage data is based on head (e311d72) compared to base (56329d1).
Patch coverage: 92.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #39      +/-   ##
==========================================
- Coverage   95.38%   95.00%   -0.39%     
==========================================
  Files           8        9       +1     
  Lines         260      280      +20     
  Branches       51       54       +3     
==========================================
+ Hits          248      266      +18     
- Misses         12       14       +2     
Impacted Files Coverage Δ
src/util/as-uint8array.js 86.66% <86.66%> (ø)
src/alloc.js 87.50% <100.00%> (+0.83%) ⬆️
src/concat.js 100.00% <100.00%> (ø)
src/from-string.js 100.00% <100.00%> (ø)
src/xor.js 90.90% <100.00%> (+0.43%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@achingbrain achingbrain merged commit 017a456 into master Sep 28, 2022
@achingbrain achingbrain deleted the fix/always-return-uint8arrays branch September 28, 2022 06:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Breaking change in minor version 3.1.0
3 participants