Re: Estimation of memory alloc for luaL_loadfile

[Bogdan Marinescu <bogdan.marinescu@...>]

Hi,

On Wed, Jul 26, 2023 at 5:49 PM Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

> Last time I looked at the source code, Lua didn't really have a concept of
> "ROMability", in the sense that you can't save data structures in ROM/flash
> and use them directly from there (without having to load then into RAM). In
> eLua it's possible to use the compiled bytecode directly from flash and
> there's also a "read-only string" type that keeps the *content* of the
> string in flash (just the content, not the whole TString data structure)
> and uses it from there. But all these require changes to the Lua source
> code.

Both would be interesting additions to next version. By "read-only
string" do you mean a string that is never freed? (All strings
in Lua are read only...)

Yes, sorry, poor choice of words on my part. I meant a TString that isn't followed by the actual string content (I hope that's still how TStrings are implemented), but rather by a pointer to the actual string content. This pointer could point to either flash or RAM, but it only saves RAM if it points to flash (or if you implement some sort of string interning mechanism in C). And of course that requires some changes in the garbage collector too (the TString is freed, but without the actual string content). I could point you to the relevant changes in the eLua source code, but that's 5.1 and I'm sure that it'd only slow you down :)

Of course an immediate extension of this would be a TString that is fully saved in flash (together with the string content) and used directly from there (and thus is never freed itself), but I think that has too many implications in terms of portability and I don't see it being implemented in mainline Lua (I'd be glad to be proven wrong though!).

Thanks,

Bogdan

 

-- Roberto