unix/mpconfigport: Disable uio.resource_stream().
This function was implemented as an experiment, and was enabled only in unix port. To remind, it allows to access arbitrary files frozen as source modules (vs bytecode). However, further experimentation showed that the same functionality can be implemented with frozen bytecode. The process requires more steps, but with suitable toolset it doesn't matter patch. This process is: 1. Convert binary files into "Python resource module" with tools/mpy_bin2res.py. 2. Freeze as the bytecode. 3. Use micropython-lib's pkg_resources.resource_stream() to access it. In other words, the extra step is using tools/mpy_bin2res.py (because there would be wrapper for uio.resource_stream() anyway). Going frozen bytecode route allows more flexibility, and same/additional efficiency: 1. Frozen source support can be disabled altogether for additional code savings. 2. Resources could be also accessed as a buffer, not just as a stream. There're few caveats too: 1. It wasn't actually profiled the overhead of storing a resource in "Python resource module" vs storing it directly, but it's assumed that overhead is small. 2. The "efficiency" claim above applies to the case when resource file is frozen as the bytecode. If it's not, it actually will take a lot of RAM on loading. But in this case, the resource file should not be used (i.e. generated) in the first place, and micropython-lib's pkg_resources.resource_stream() implementation has the appropriate fallback to read the raw files instead. This still poses some distribution issues, e.g. to deployable to baremetal ports (which almost certainly would require freezeing as the bytecode), a distribution package should include the resource module. But for non-freezing deployment, presense of resource module will lead to memory inefficiency. All the discussion above reminds why uio.resource_stream() was implemented in the first place - to address some of the issues above. However, since then, frozen bytecode approach seems to prevail, so, while there're still some issues to address with it, this change is being made. This change saves 488 bytes for the unix x86_64 port.
This commit is contained in:
parent
d21d029d55
commit
e7fc765880
@ -103,7 +103,6 @@
|
||||
#endif
|
||||
#define MICROPY_PY_CMATH (1)
|
||||
#define MICROPY_PY_IO_FILEIO (1)
|
||||
#define MICROPY_PY_IO_RESOURCE_STREAM (1)
|
||||
#define MICROPY_PY_GC_COLLECT_RETVAL (1)
|
||||
#define MICROPY_MODULE_FROZEN_STR (1)
|
||||
|
||||
|
@ -938,7 +938,11 @@ typedef double mp_float_t;
|
||||
|
||||
// Whether to provide "uio.resource_stream()" function with
|
||||
// the semantics of CPython's pkg_resources.resource_stream()
|
||||
// (allows to access resources in frozen packages).
|
||||
// (allows to access binary resources in frozen source packages).
|
||||
// Note that the same functionality can be achieved in "pure
|
||||
// Python" by prepocessing binary resources into Python source
|
||||
// and bytecode-freezing it (with a simple helper module available
|
||||
// e.g. in micropython-lib).
|
||||
#ifndef MICROPY_PY_IO_RESOURCE_STREAM
|
||||
#define MICROPY_PY_IO_RESOURCE_STREAM (0)
|
||||
#endif
|
||||
|
Loading…
Reference in New Issue
Block a user