-->
Page 1 of 1

What is node.heap() actually reporting...

PostPosted: Wed Nov 18, 2015 6:40 pm
by xtal
Using sdk 1.4.0 I'm apparently near the not enough memoy wall, my favorite place.....
node heap shows 13000-14000 , but if I add a 60 char statement I get not enough memory..

Is node.heap showing the total available fragmented memory ?
Or is it showing the largest area available I don't remember seeing info on this in the FAQ....

If it is the total Fragmented then what is the preferred code layout?
ie Vars, Functions, Code or Functions, Code, Vars or other?

Re: What is node.heap() actually reporting...

PostPosted: Wed Nov 18, 2015 7:22 pm
by TerryE
It's pretty dumb in its estimate as it simply uses the SDK API call system_get_free_heap_size(), and AFAIK this simply does a count up / down on malloc and free requests. However: (i) heap can get badly fragmented and (ii) any compilation hammers the heap and fragments it badly. To an extent you can mitigate this by doing luac.cross on your host to compile code on the host or using node.compile() on the target to save the code to lc files and run this.

If you need to keep debug line info (on the latest dev builds), then do your build with #define LUA_OPTIMIZE_DEBUG 2 (see Lua Compact Debug (LCD), and do the string.dump(loadfile(file)) trick to write out lc files which contain compressed line info. Do this as a separate "Compile my code" step and then restart before running the app. This gives you the double win of saving about 40% of your heap used to store the Lua code and avoiding the compile hit.

You could also use some of the overlay techniques that I discuss in my FAQ.