Issue #178: modules are now cached
Dean Hall
As a part of Issue #178, I created a dict in the builtins module that
caches modules so they aren't imported a 2nd time. Per recent
discussion, this caching is also necessary to match CPython behavior.
The good news is that I've checked it in and it works (and ipm works
this time, too).
The bad news is that the dict takes up a little bit more heap. And
it's in builtins, so it gets used immediately and applies to everybody.
For people who need to load a module and then delete references to it
to have it garbage collected, heres how:
import mymodule
# Use mymodule.
# ...
# done with mymodule
del mymodule, __md['mymodule']
I decided not to do it the sys.modules way because anybody who is low
enough of RAM to need to delete modules is probably too low on RAM to
import sys just to delete other modules.
share and enjoy,
!!Dean
Oscar Lindberg
The project that I am trying to run with pymite is about 10 different
modules, with most of them importing from some of the others. I can
now set the heap to about half what I needed before when the modules
were not cached.
What is the principle in p14p with optional features? I know that
there are a few defines that can turn off support for different things
in the vm. Would CACHE_MODULES be a candidate?
For me and my projects, this change is very welcome. But I do
understand that for programs running on platforms with very limited
memory this might not be a good thing. If it was possible, it would be
awesome if everyone could pick and choose the features they need,
without being burdened by the "unnecessary" stuff.
> --
> You are subscribed to the "python-on-a-chip" (or p14p for short) Google
> Group.
> Site: http://groups.google.com/group/python-on-a-chip
>
Dean Hall
optional features.
2 years ago as the PyMite VM started growing more and more features,
its RAM footprint started growing along with those features. In order
to keep that footprint under control, I started using
HAVE_SOME_FEATURE definitions to make pieces of code compile
conditionally based on a platform's configuration as set in
pmfeatures.h (at the time) and now in pmfeatures.py. A developer
could selectively enable the features he wanted by defining the
HAVE_SOME_FEATURE or leave it disabled by not defining it.
That system work well except for the cases where there needed to be
corresponding code in the Python libraries such as __bi.py or sys.py.
I still haven't implemented a good solution for that. This is why you
still see the bytearray class commented out in src/lib/__bi.py. The
econotag platform that uses bytearrays then has a patch file to
uncomment that code in __bi.py that is applied during its build
process. Ugly, but it works.
Looking forward to r10 (The Big Rewrite), the amount of RAM that's
going to be saved by the redesign is going to allow *most* of the
HAVE_ features to be enabled. So between now and r10, I'm not going
to worry about creating new feature definitions. I'm going to let it
slide and reassess the RAM budget as I make the big changes and get
closer to the 10 release.
!!Dean
jani basha
import mymodule
# Use mymodule.
# ...
# done with mymodule
del mymodule, __md['mymodule']