mirror of
https://github.com/licsber/micropython.git
synced 2024-09-20 09:00:23 +08:00
docs/reference: Update constrained docs now that tuples can be const.
Signed-off-by: Damien George <damien@micropython.org>
This commit is contained in:
parent
865b61dac2
commit
9ab66b50cb
@ -126,8 +126,9 @@ that the objects remain in flash memory rather than being copied to RAM. The
|
|||||||
Python built-in types.
|
Python built-in types.
|
||||||
|
|
||||||
When considering the implications of frozen bytecode, note that in Python
|
When considering the implications of frozen bytecode, note that in Python
|
||||||
strings, floats, bytes, integers and complex numbers are immutable. Accordingly
|
strings, floats, bytes, integers, complex numbers and tuples are immutable.
|
||||||
these will be frozen into flash. Thus, in the line
|
Accordingly these will be frozen into flash (for tuples, only if all their
|
||||||
|
elements are immutable). Thus, in the line
|
||||||
|
|
||||||
.. code::
|
.. code::
|
||||||
|
|
||||||
@ -146,16 +147,16 @@ As in the string example, at runtime a reference to the arbitrarily large
|
|||||||
integer is assigned to the variable ``bar``. That reference occupies a
|
integer is assigned to the variable ``bar``. That reference occupies a
|
||||||
single machine word.
|
single machine word.
|
||||||
|
|
||||||
It might be expected that tuples of integers could be employed for the purpose
|
Tuples of constant objects are themselves constant. Such constant tuples are
|
||||||
of storing constant data with minimal RAM use. With the current compiler this
|
optimised by the compiler so they do not need to be created at runtime each time
|
||||||
is ineffective (the code works, but RAM is not saved).
|
they are used. For example:
|
||||||
|
|
||||||
.. code::
|
.. code::
|
||||||
|
|
||||||
foo = (1, 2, 3, 4, 5, 6, 100000)
|
foo = (1, 2, 3, 4, 5, 6, 100000, ("string", b"bytes", False, True))
|
||||||
|
|
||||||
At runtime the tuple will be located in RAM. This may be subject to future
|
This entire tuple will exist as a single object (potentially in flash if the
|
||||||
improvement.
|
code is frozen) and referenced each time it is needed.
|
||||||
|
|
||||||
**Needless object creation**
|
**Needless object creation**
|
||||||
|
|
||||||
@ -214,7 +215,7 @@ buffer; this is both faster and more efficient in terms of memory fragmentation.
|
|||||||
|
|
||||||
**Bytes are smaller than ints**
|
**Bytes are smaller than ints**
|
||||||
|
|
||||||
On most platforms an integer consumes four bytes. Consider the two calls to the
|
On most platforms an integer consumes four bytes. Consider the three calls to the
|
||||||
function ``foo()``:
|
function ``foo()``:
|
||||||
|
|
||||||
.. code::
|
.. code::
|
||||||
@ -222,12 +223,16 @@ function ``foo()``:
|
|||||||
def foo(bar):
|
def foo(bar):
|
||||||
for x in bar:
|
for x in bar:
|
||||||
print(x)
|
print(x)
|
||||||
|
foo([1, 2, 0xff])
|
||||||
foo((1, 2, 0xff))
|
foo((1, 2, 0xff))
|
||||||
foo(b'\1\2\xff')
|
foo(b'\1\2\xff')
|
||||||
|
|
||||||
In the first call a tuple of integers is created in RAM. The second efficiently
|
In the first call a `list` of integers is created in RAM each time the code is
|
||||||
|
executed. The second call creates a constant `tuple` object (a `tuple` containing
|
||||||
|
only constant objects) as part of the compilation phase, so it is only created
|
||||||
|
once and is more efficient than the `list`. The third call efficiently
|
||||||
creates a `bytes` object consuming the minimum amount of RAM. If the module
|
creates a `bytes` object consuming the minimum amount of RAM. If the module
|
||||||
were frozen as bytecode, the `bytes` object would reside in flash.
|
were frozen as bytecode, both the `tuple` and `bytes` object would reside in flash.
|
||||||
|
|
||||||
**Strings Versus Bytes**
|
**Strings Versus Bytes**
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user