opening settings editor consumes app memory

“In can't access strings like directory/arrays directly but first has to put rez,strings.str1b... to array, how is it possible to take memory, add more code to write and do nothing except”

You can’t access resource strings directly because resources aren’t loaded in memory, as you pointed out. The resource table (which is loaded the first time you call loadResource()) only has resource IDs, not resource contents.

So the contents of your app settings strings don’t take up memory at runtime, but the more strings you have, the more memory is wasted (if you call loadResource()) once. I just don’t understand why the app settings and fit contributor strings need to be in the pool of resources that goes on the device, since the device won’t use them.

If you’re suggesting that there should a way to load all resource strings at once into an array using a single call to loadResource(), this would not be a great design (IMO), because then you’d have a memory spike equal to the size of *all* your strings. In some cases (or most cases), this would be just as bad (or worse) than having all your strings hardcoded in the app.

(As a side note, I often do hardcode strings in my app because calling loadResource() wastes so much memory by loading the whole resource table into memory - this is obviously only for apps where I don’t need resources for anything else and where I don’t want to localize strings.)

“In can't access strings like directory/arrays directly but first has to put rez,strings.str1b... to array, how is it possible to take memory, add more code to write and do nothing except”

You can’t access resource strings directly because resources aren’t loaded in memory, as you pointed out. The resource table (which is loaded the first time you call loadResource()) only has resource IDs, not resource contents.

So the contents of your app settings strings don’t take up memory at runtime, but the more strings you have, the more memory is wasted (if you call loadResource()) once. I just don’t understand why the app settings and fit contributor strings need to be in the pool of resources that goes on the device, since the device won’t use them.

If you’re suggesting that there should a way to load all resource strings at once into an array using a single call to loadResource(), this would not be a great design (IMO), because then you’d have a memory spike equal to the size of *all* your strings. In some cases (or most cases), this would be just as bad (or worse) than having all your strings hardcoded in the app.

(As a side note, I often do hardcode strings in my app because calling loadResource() wastes so much memory by loading the whole resource table into memory - this is obviously only for apps where I don’t need resources for anything else and where I don’t want to localize strings.)

"or symbol should have constructor from string_number"

Yeah, the inability to convert from a symbol to a number is a separate issue which isn't directly related to what I was talking about.

I get that you don't like to have another array of symbols because it wastes memory but there's not much that can be done about that, either. I think the idea is that the dev is not supposed to know about the implementation details of Symbol, just the fact that it's a "lightweight unique identifier".

"But I'm almost sure that more number of  strings = more memory need (more members)."

Yes that's what I said. But I also said that the *contents* of the strings don't matter. Rez.strings has resource IDs/symbols, not actual strings.

You can test this easily by creating two strings in your resources, each 10 chars long, and calling loadResource() once (on one of the strings).

Now change the *other* string to be much longer (like 255 chars) and run your code again. You will see that the peak memory will remain unchanged (as well as the memory taken up by Rez/Strings.

Just now I tried a similar test with one of my apps, which calls loadResource() at least once:

- Change one string (not loaded by the app) to be a lot longer: memory usage does not increase by a single byte

- Add one string: total memory usage increases (global memory usage increases by exactly 12 bytes). 12 bytes per string is *huge*, especially for devices with only 16 KB or 32 KB of RAM for a data field.

Why do I care? It goes back to strings that are only used for application settings. If my app calls loadResource() at least once, then every string I add (even if it's just for app settings) wastes memory. But at least it doesn't matter how long the strings are.

It also means that I can store certain kinds of data as a very long string resource to try and save memory (although this kind of trick is only useful in very limited circumstances, like for old devices where JSON resources are unavailable and when the data that's being stored is only needed at init time, as opposed to all the time.)

I don't agree because as you noticed, when you load one string all strings are loaded. why? by design... probably:

BUILD: globals/Rez/Strings:
BUILD:   CLASSDEF
BUILD:     APPTYPE 127
BUILD:     MODULEID globals/Rez/Strings
BUILD:     PARENT globals/Rez

1. each string has id_string

2. compiler change id_string to symbol

3. compiler build class Rez and inside another Strings/Fonts.etc Class String has members, each member is one id_string 

4. when you load string system create object new Strings and loads all strings to the memory assuming that strings will be used many times, unlike, for example, fonts.

But it doesn't matter, maybe I'm wrong (because you can't read strings during lowpower what suggest you are right)  But I'm almost sure that more number of  strings = more memory need (more members).

If you have string not connected with context e.g. rez.string.name_of_steps there is no problem. But if you have string for days, months etc that are connected with numbers (JAN=1, FEB=2...) you have to read separately to array of rez... What about when you want to prints numbers in words?

The problems is in ID that should be numbers:

id=800 JAN

id=801 FEB

loadstring(currentmonth+800)

simple...

or symbol should have constructor from string_number

id="800" JAN

id="801" FEB

for(i=0; i<11; i++)

{

months[i] = loadstring(new symbol((i+800).toString())

}

simple...