Skip to content

Conversation

@ChALkeR
Copy link
Contributor

@ChALkeR ChALkeR commented Oct 14, 2025

Depends on:

Main:

==== base32 ====
base32 (encode) 32 B scure x 715,819 ops/sec @ 1μs/op ± 1.30% (1μs..5ms)
base32 (decode) 32 B scure x 1,273,885 ops/sec @ 785ns/op ± 2.69% (583ns..7ms)
base32 (encode) 64 B scure x 408,663 ops/sec @ 2μs/op
base32 (decode) 64 B scure x 753,012 ops/sec @ 1μs/op ± 1.09% (1μs..1ms)
base32 (encode) 1 KB scure x 26,949 ops/sec @ 37μs/op ± 1.72% (35μs..8ms)
base32 (decode) 1 KB scure x 50,607 ops/sec @ 19μs/op
base32 (encode) 8 KB scure x 3,285 ops/sec @ 304μs/op
base32 (decode) 8 KB scure x 5,789 ops/sec @ 172μs/op
base32 (encode) 1 MB scure x 13 ops/sec @ 74ms/op ± 2.81% (69ms..80ms)
base32 (decode) 1 MB scure x 25 ops/sec @ 39ms/op ± 3.51% (36ms..50ms)

This branch:

==== base32 ====
base32 (encode) 32 B scure x 1,001,001 ops/sec @ 999ns/op ± 1.57% (791ns..3ms)
base32 (decode) 32 B scure x 1,908,396 ops/sec @ 524ns/op ± 4.44% (333ns..8ms)
base32 (encode) 64 B scure x 579,374 ops/sec @ 1μs/op ± 1.27% (1μs..1ms)
base32 (decode) 64 B scure x 1,019,367 ops/sec @ 981ns/op ± 4.69% (791ns..15ms)
base32 (encode) 1 KB scure x 39,094 ops/sec @ 25μs/op
base32 (decode) 1 KB scure x 94,277 ops/sec @ 10μs/op
base32 (encode) 8 KB scure x 5,125 ops/sec @ 195μs/op
base32 (decode) 8 KB scure x 12,137 ops/sec @ 82μs/op
base32 (encode) 1 MB scure x 26 ops/sec @ 38ms/op ± 3.63% (35ms..47ms)
base32 (decode) 1 MB scure x 93 ops/sec @ 10ms/op

This can be further (significantly) optimized with TextEncoder/TextDecoder if available and not a polyfill

Also, cloc reports 519 lines of code in index.ts on this branch, but 563 in main
This simplifies things

@paulmillr
Copy link
Owner

paulmillr commented Oct 14, 2025

note that alphabet is used here:

https://github.com/paulmillr/scure-bip39/blob/753ea75ac2621b71b64e7899bd72cfd140107296/src/index.ts#L54-L65

we can probably make a specific version for bip39, if the perf benefits are really good, but backwards compat is better be good

@paulmillr
Copy link
Owner

This can be further (significantly) optimized with TextEncoder/TextDecoder if available and not a polyfill

Can we use it when it's available and fallback when it's not?

@ChALkeR
Copy link
Contributor Author

ChALkeR commented Oct 14, 2025

@paulmillr yes, that'll be just a few extra lines of code
I'll file that in a separate PR on top of this

@paulmillr
Copy link
Owner

paulmillr commented Oct 14, 2025

overall utils export (alphabet etc) is non-core functionality so i'm leaning towards just breaking it. 2.0.0 was only recently released, which means very few people upgraded. Also scure-bip39 uses 2.0.0 of scure-base, which means we can use separate bip39-specific alphabet function in 2.1.0.

I've also searched across github and only 2 projects seem to be using utils:

@ChALkeR
Copy link
Contributor Author

ChALkeR commented Oct 14, 2025

@paulmillr this would still be a semver-major though
Also for radix and bech reasons

@paulmillr
Copy link
Owner

@ChALkeR radix is also non-core functionality.

Can we leave bech inputs as-is? This would allow it to be released as 2.1.

@paulmillr
Copy link
Owner

see this https://www.npmjs.com/package/@scure/base?activeTab=versions - i'd argue that for non-core functionality, pragmatically, we can break stuff for 1% of weekly users.

"ideally" v3 would've been released for this change but it's painful to not have synced scure packages (base, bip32, bip39, btc-signer)

@paulmillr
Copy link
Owner

another reason not to break bech is the fact that it's using 5-bit words and NOT real uint8 stuff.

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.

2 participants