Launching a separate process instead of calling a memory intensive function

Discussion about programs, libraries and tools that work with MicroPython. Mostly these are provided by a third party.
Target audience: All users and developers of MicroPython.
kristopher
Posts: 5
Joined: Tue Mar 26, 2019 10:25 am

Re: Launching a separate process instead of calling a memory intensive function

Post by kristopher » Thu Mar 28, 2019 11:47 am

stijn wrote:
Thu Mar 28, 2019 9:12 am
As far as your pseudocode goes: depending on how 'pseudo' it is, there are probably other ways which are less memory-hungry/memory-fragmentation-hungry then constructing a lot of temproary lists.
I thought that the whole idea of using python is that list operations (creation, disposal, insertion, deletion) are efficient and are subject to memory reuse when possible. Of course I can always resort to manually writing to buffers and build my format one write at a time but how that would be different from writing C code from an expressiveness point of view.

The issue here is not that I can't do it - it is more than doable just I want to do it preserving the same python spirit as much as possible (hope this came out right).

As for the references that deny me of free available memory probably will have to strip down everything and start from scratch because trying out the sample code provided by Dave seems to get more or less the same results. So if there will not a lot of frequent object creation after the initial message format creation (just occasional integers and lists (no further dynamic string creation)) the program can run more or less indefinitely.

cefn
Posts: 230
Joined: Tue Aug 09, 2016 10:58 am

Re: Launching a separate process instead of calling a memory intensive function

Post by cefn » Thu Mar 28, 2019 4:18 pm

Working on similar issues, I found myself drawn to pfalcon's utemplate library https://github.com/pfalcon/utemplate which turns templates into generators consuming information from a dictionary. Assuming your logic is fixed, you can 'precompile' the generators and store them as python.

That way you are using a nice high-level templating language oriented towards python (a subset of Jinja2) but the routine will use overwhelmingly transient stack memory combined with function definitions which can be stored as .mpy bytecode or even frozen in the firmware.

Post Reply