We may have a memory leak with Module.removeAllCached(), which is pretty ironic since I hoped to use it and free some memory ;P
A bit of context. I'm trying various means to overtake the deadly 10000 character limit.
From the last month experiments, this is roughly the maximum number of symbols your application could have to fit in the Bangle's RAM.
I found a nice way to split my code into several chunks, each being a file.
My ES6 source code is leveraging dynamic imports, which instructs Rollup to produce several chunks.
A small Rollup plugin of mine turns the chunk into Bangle's files.
The app is written so screens are stored as files. Displaying a screen is simply requiring the relevant file, and calling the build() function it exposes.
Now if you launch the app, and cycle through the various screens with middle button, at some point you should have a LOW_MEMORY error.
Since object returned by require() are cached, I've tried to call Module.removeAllCached() after a screen was required, so it could claim the space from the previous screen.
You'll be surprised to get the LOW_MEMORY error the very first time you load next screen.
Few more experiments makes me believe that Module.getCached() also have similar side effect.
Could it be that listing cached modules (which removeAllCached() starts with) is eating more RAM that it should?
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Hello folks!
We may have a memory leak with
Module.removeAllCached()
, which is pretty ironic since I hoped to use it and free some memory ;PA bit of context. I'm trying various means to overtake the deadly 10000 character limit.
From the last month experiments, this is roughly the maximum number of symbols your application could have to fit in the Bangle's RAM.
I found a nice way to split my code into several chunks, each being a file.
My ES6 source code is leveraging dynamic imports, which instructs Rollup to produce several chunks.
A small Rollup plugin of mine turns the chunk into Bangle's files.
The app is written so screens are stored as files. Displaying a screen is simply requiring the relevant file, and calling the
build()
function it exposes.Here is the code,
and here is the minified, split output that you can run on your watch.
Now if you launch the app, and cycle through the various screens with middle button, at some point you should have a LOW_MEMORY error.
Since object returned by
require()
are cached, I've tried to callModule.removeAllCached()
after a screen was required, so it could claim the space from the previous screen.Here is the minified code, same as previously but with the call.
You'll be surprised to get the LOW_MEMORY error the very first time you load next screen.
Few more experiments makes me believe that
Module.getCached()
also have similar side effect.Could it be that listing cached modules (which
removeAllCached()
starts with) is eating more RAM that it should?