esp32: Add MICROPY_GC_INITIAL_HEAP_SIZE option and tune it. #13219
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is an alternative to #13035. |
|
Code size report: |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #13219 +/- ##
=======================================
Coverage 98.40% 98.40%
=======================================
Files 159 159
Lines 21075 21075
=======================================
Hits 20738 20738
Misses 337 337 ☔ View full report in Codecov by Sentry. |
|
LGTM |
There are two main changes here to improve the calculation of the size of the next heap area when automatically expanding the heap: - Compute the existing total size by counting the total number of GC blocks, and then using that to compute the corresponding number of bytes. - Round the bytes value up to the nearest multiple of BYTES_PER_BLOCK. This makes the calculation slightly simpler and more accurate, and makes sure that, in the case of growing from one area to two areas, the number of bytes allocated from the system for the second area is the same as the first. For example on esp32 with an initial area size of 65536 bytes, the subsequent allocation is also 65536 bytes. Previously it was a number that was not even a multiple of 2. Signed-off-by: Damien George <damien@micropython.org>
This gets back the old heap-size behaviour on ESP32, before auto-split-heap was introduced: after the heap is grown one time the size is 111936 bytes, with about 40k left for the IDF. That's enough to start WiFi and do a HTTPS request. Signed-off-by: Damien George <damien@micropython.org>
93c3b03 to
f6d6308
Compare
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR consists of two commits.
First, there are changes to the GC to improve the calculation of the size of the next heap area when automatically expanding the heap:
This makes the calculation slightly simpler and more accurate, and makes sure that, in the case of growing from one area to two areas, the number of bytes allocated from the system for the second area is the same as the first. For example on esp32 with an initial area size of 65536 bytes, the subsequent allocation is also 65536 bytes. Previously it was a number that was not even a multiple of 2.
Second, a change to esp32 to add
MICROPY_GC_INITIAL_HEAP_SIZEand tune its value. This gets back the old heap-size behaviour on ESP32, before auto-split-heap was introduced: after the heap is grown one time the size is 111936 bytes, with about 40k left for the IDF. That's enough to start WiFi and do a HTTPS request.