Feature-request: split the strings.xml for in-device and settings related strings

In other words, as discussed years ago, it's a compile-time change which every device can benefit from.

To be clear, I also tried fr955 with the same results (strings with the settings scope are excluded from the PRG).

So  I think the memory savings comes from when an app calls loadResource() (at least once), the resource table is loaded in memory, and there's no entries for those strings. (I think you'll just save a constant amount of memory per string, since the resource table only has resource IDs as values, not contents)

In other words, as discussed years ago, it's a compile-time change which every device can benefit from.

To be clear, I also tried fr955 with the same results (strings with the settings scope are excluded from the PRG).

So  I think the memory savings comes from when an app calls loadResource() (at least once), the resource table is loaded in memory, and there's no entries for those strings. (I think you'll just save a constant amount of memory per string, since the resource table only has resource IDs as values, not contents)

Each module scope variable takes 16 bytes in the data segment

I misremembered this. It's actually only 8 bytes. The symbol is stored in 3 bytes, there's a flag byte (indicating data type amongst other things), and then 4 bytes for the value (which in this case is just a Number). So presumably the resource table uses 16 bytes per string. I guess it needs address, length, id, and something else?

maybe 24 but memory monitor shows data only in kB...

why????

Each module scope variable takes 16 bytes in the data segment. That's fixed overhead whether you call loadResource or not. Then I'm guessing the resource table has 8 bytes per resource, but only gets allocated on the first call to loadResource. Which would give 24 bytes per resource. 

ID is quite big...

without scope

with scope

there is 0.8kB difference, I've added scope for 32 strings -> 800/32= 25 bytes/string

Rez.mir

...

module Strings {
        ...
        var StrID as Symbol;

        ...
    }

...

the resource table is loaded in memory, and there's no entries for those strings

Exactly.