-
Notifications
You must be signed in to change notification settings - Fork 7.6k
fix(core): StreamString performance improvements with large buffers (StreamString::readBytes()) #11229
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
base: master
Are you sure you want to change the base?
Conversation
👋 Hello mathieucarbou, we appreciate your contribution to this project! 📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more. 🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project. Click to see more instructions ...
Review and merge process you can expect ...
|
Test Results 76 files 76 suites 12m 42s ⏱️ Results for commit 436b1ef. ♻️ This comment has been updated with latest results. |
a320ffe
to
3418c6c
Compare
3418c6c
to
436b1ef
Compare
Memory usage test (comparing PR against master branch)The table below shows the summary of memory usage change (decrease - increase) in bytes and percentage for each target.
Click to expand the detailed deltas report [usage change in BYTES]
|
Using
StreamString
on large buffers causes large movements of memory data when reading which can cause the TWDT to trigger, heap fragmentation or crash due to allocation failures.StreamString
is definitely slower than cbuf.h for large buffers.Explanation of the issue with a small MRE: ESP32Async/ESPAsyncWebServer#148 (comment)
This issue was discovered in the OpenDTU project : tbnobody/OpenDTU#2535
Note: the code is not tested yet: this is a proposal meant to open a discussion on a solution.
Sadly it does not solve the issue fully but aims at being backward compatible. It avoids at least to do a memory move for each byte read.
Like explained in the links above, to correcly fix the issue, we would need to make the String immutable when the first read occurs, which implies:
This would allow the StreamString to:
Another implementation version is available here: #11232, which is even faster but not backward compatible if user is accessing the String API after a read.