Skip to content

Tweaked base64_encode_value in cores/esp8266/libb64/cencode.cpp #9227

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

Closed
wants to merge 2 commits into from
Closed

Tweaked base64_encode_value in cores/esp8266/libb64/cencode.cpp #9227

wants to merge 2 commits into from

Conversation

LinRaymond2006
Copy link

Referred to the original libb64 implementation and optimized time complexity of base64_encode_value from O(n) to O(1). The existing method, which uses if-else statement, can slow down the execution speed.

Refered to the original libb64 implementation and optimized time
complexity of `base64_encode_value` from O(n) to O(1)

Signed-off-by: linraymond2006 <[email protected]>
Signed-off-by: linraymond2006 <[email protected]>
@mcspr
Copy link
Collaborator

mcspr commented Jan 29, 2025

So there are two places that encode b64 for our libs - HTTPClient and WebServer. Both client and server encode authorization header. Server also encodes file hash for etag. Which one is the problem here?

Pretty sure you've seen the history of the file. Original implementation was from libb64, but the lookup table placed in flash instead of ram (like it is here; since it is not marked with PROGMEM which forces it into .irom section, it never gets loaded into ram). #6607 traded flash space for some math. PR trades it back for ram. Any significant reason to make the change?

@LinRaymond2006
Copy link
Author

Oh I haven't notice that. Sorry for the confusion.

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