Usable memory

[espruino-discuss]

Posted at 2022-12-31 by !evil

Hi,

I wonder why the amount of usable memory is relatively small. Bangle.js 1 has 2584 blocks with 13 bytes each, in total 33.592 kB. This means the runtime requires ~30kB. From https://www.espruino.com/Performance:

Espruino is designed to run on devices with very small amounts of RAM available (under 8kB) ...

Obviously there is lots of code for Bangle.js in libs/banglejs/ and I guess elsewhere too, but it would be interesting to know what is taking up that space.

related: https://forum.espruino.com/conversations/372543/

[gfwilliams]

Posted at 2023-01-06 by @gfwilliams

There's the Bluetooth stack that uses 10k of RAM, but also we need to have a certain amount of free RAM (~10kb) for the execution stack.

Newer builds have process.memory().stackFree and on Bangle.js 1 this gives 9552, so around the 10k

So 10k execution + 10k bluetooth + 34k vars leaves 10k for the rest of the interpreter, Tensorflow, etc. It does seem a bit high, but it's not that bad.

There's a script called scripts/find_big_ram.sh in the Espruino repo, and if you run it on the list file you get something like:

20002d98 g     O .bss	00000043 .hidden graphicsInternal
2000c20c l     O .bss	00000048 m_chunk_queue
20002d48 g     O .bss	00000050 .hidden gpsFix
2000cf3c l     O .bss	00000052 gpsLine
2000c93b g     O .bss	00000052 .hidden gpsLastLine
2000d498 g     O .bss	0000005c .hidden jit
2000c2aa g     O .bss	00000060 .hidden m_connections.lto_priv.693
20002c44 l     O .data	00000060 impure_data
2000c47c g     O .bss	00000068 .hidden m_queue.lto_priv.687
2000c154 g     O .bss	0000006c .hidden m_cb.lto_priv.529
2000c7ec l     O .bss	00000070 BLE_EVT_BUFFER.16447
2000c35c l     O .bss	00000078 m_op_queue.lto_priv.488
2000b134 g     O .bss	0000008c .hidden m_ams_c.lto_priv.476
2000c870 l     O .bss	00000096 accHistory
2000c668 l     O .bss	000000a0 m_write_buffer_records
2000ce90 l     O .bss	000000a8 APP_TIMER_BUF.16995
2000c9cc g     O .bss	000000b4 .hidden hrmFilter
2000d4fe g     O .bss	00000100 .hidden txBuffer
2000b920 g     O .bss	00000120 .hidden ams_m_tx_buffer.lto_priv.676
2000c53c g     O .bss	00000120 .hidden m_tx_buffer.lto_priv.677
2000bce4 g     O .bss	00000160 .hidden m_ancs_c.lto_priv.549
2000b49c g     O .bss	00000178 .hidden m_hids.lto_priv.552
2000ccfc g     O .bss	00000190 .hidden utilTimerTasks
2000be88 g     O .bss	00000200 .hidden m_attr_message.lto_priv.666
2000b1f4 g     O .bss	00000260 .hidden m_ble_db_discovery.lto_priv.686
2000ba50 l     O .bss	00000280 buffer_memory.10767
2000b620 g     O .bss	00000288 .hidden m_pending_user_evts.lto_priv.705
2000cf95 l     O .bss	00000500 ioBuffer
20002de8 g     O .bss	00008338 .hidden jsVars

I skipped out anything under 64 bytes. If I add those I get 7557 bytes, so that's about what we'd expect I guess.

On the whole the m_* variables are from the Nordic SDK, so there's not a great deal we can do about those

[espruino-discuss]

Posted at 2023-01-06 by !evil

I agree, 7.6k is not bad. And considering bluetooth a vital part, there isn't much room for improvement except for stack size. Thanks!