-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
Compile constant tuples to constant objects immediately in the parser #8504
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
Conversation
One thing to decide is if def f():
for x in (1, 2, 3):
print(x) With this PR, the above function can run with the heap locked. Would be nice to guarantee such things unconditionally (ie for all ports/builds). |
As an example, consider this code: x0 = (1,)
x1 = (1, 2)
x2 = (1, 1 << 100)
x3 = (None, False, True, ...)
x4 = ("str", b"bytes")
x5 = ((),)
x6 = ((1,),)
x7 = ((1, 2),)
x8 = (1, "str", (), ("nested", 2, ((False, True), None, ...))) Prior to this PRThe .mpy file looks like this:
After this PRThe .mpy file looks like this:
You can see that all these constant tuples are truly constants in the bytecode. |
Codecov Report
@@ Coverage Diff @@
## master #8504 +/- ##
==========================================
- Coverage 98.25% 98.22% -0.03%
==========================================
Files 154 154
Lines 20288 20368 +80
==========================================
+ Hits 19933 20006 +73
- Misses 355 362 +7
Continue to review full report at Codecov.
|
Performance change with this PR, on PYBv1.0:
You can see that it's mostly unchanged. Except for the import tests which are a bit slower because now the tuple are are being created on import, rather than it runtime (and in these tests the code that creates/uses the tuples is never run). |
bf20df4
to
1c9d055
Compare
This is awesome. I make heavy use of constant tuples, and this is great! Possible naive question, but are there implications for named tuples here or is that different? |
Namedtuple's are not impacted, they are still as they were. Although, it will be more efficient to create them if you use a tuple of strings like |
Looks worth having it always on, but I'd add it explicitly to the relevant doc section(s) so it gets widely known then |
It's currently enabled at The only other option is to make it unconditional (ie non optional). But I think it makes sense to keep it optional. After all, we've lived this long without it 😄 |
07e743e
to
3bb8dd8
Compare
To keep the separate parts of the code that use these values in sync. And make it easier to add new object types. Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
To give more information when printing the parse tree. Signed-off-by: Damien George <damien@micropython.org>
This commit adds support to the parser so that tuples which contain only constant elements (bool, int, str, bytes, etc) are immediately converted to a tuple object. This makes it more efficient to use tuples containing constant data because they no longer need to be created at runtime by the bytecode (or native code). Furthermore, with this improvement constant tuples that are part of frozen code are now able to be stored fully in ROM (this will be implemented in later commits). Code size is increased by about 400 bytes on Cortex-M4 platforms. See related issue micropython#722. Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
This also simplifies how constants are frozen. Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Damien George <damien@micropython.org>
3bb8dd8
to
9ab66b5
Compare
Update pt_BR.po
This PR adds support to the parser to "compile" tuples that contain only constant elements directly to a tuple object. This makes it more efficient to use constant tuples because they no longer need to be created at runtime by the bytecode (or native code).
This PR implements the following:
mpy-tool.py
to get frozen code size down furtherCode size change for this entire PR is:
This size change is broken down into the following:
MICROPY_COMP_TUPLE_FOLDING
)Some ports like unix 64 have a decrease in frozen code size which mostly offsets the increase due to the new feature. Others like cc3200 don't have much/any frozen code and so see a bigger increase. Bare-arm/minimal have no change because they don't enable the feature.
The main benefits of this change are:
The downsides are:
Although it's not a clear win on all fronts, IMO I think this feature is well worth it, mainly because it saves RAM / reduces heap allocations. It also addresses the long-standing issue #722.