Skip to content

Conversation

@juj
Copy link
Collaborator

@juj juj commented Jan 16, 2026

When building -sSINGLE_FILE builds with -sSINGLE_FILE_BINARY_ENCODE enabled, the base64Decode function was being emitted, and Closure was unable to DCE away the dependent base64ReverseLookup variable. So optimize this away manually to save code size.

…nabled, the base64Decode function was being emitted, and Closure was unable to DCE away the dependent base64ReverseLookup variable. So optimize this away manually to save code size.
@juj juj added the code size label Jan 16, 2026
// Decodes a _known valid_ base64 string (without validation) and returns it as a new Uint8Array.
// Benchmarked to be around 5x faster compared to a simple
// "Uint8Array.from(atob(b64), c => c.charCodeAt(0))" (TODO: perhaps use this form in -Oz builds?)
#if !JS_BASE64_API
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does does JS_BASE64_API relate to SINGLE_FILE_BINARY_ENCODE? The PR description only talks about that later.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah sorry, that was not so clear with GitHub diff.

By static reading the base64Decode() function starts

  $base64Decode: (b64) => {
#if JS_BASE64_API
    return Uint8Array.fromBase64(b64);
#else

i.e. the base64ReverseLookup object is never accessed if JS_BASE64_API is defined. So I updated the ifdef here to be consistent with that scenario as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants