Limit code/resources to glance only?

It isn't possible to do what you're asking for code, due to the way PRGs are laid out. The foreground process includes all the code/data from the glance. And both the glance and foreground process include all the code/data from the background.

- PRGs are laid out like this, roughly speaking:

--------------------------------- beginning of PRG ------------------
| shared static data            |                         |    |    |
---------------------------------                         |    |    |
| shared global data            |                        [B]  [G]  [F]
---------------------------------                         |    |    |
| background data (:background) |                         |    |    |
--------------------------------- end of background data --    |    |
| glance data (:glance)         |                              |    |
--------------------------------- end of glance data -----------    |
| foreground data               |                                   |
--------------------------------- beginning of resources ------------
| resources                     |
--------------------------------- end of PRG

[B] - background process
[G] - glance process
[F] - foreground process

You can see this layout for yourself if you compile a PRG for an app that has code/data annotated with :glance and :background, using the -g compiler option.

- The background process will load everything from the beginning of the PRG to the end of the background data.

- The glance process will load everything from the beginning of the PRG to the end of the glance data.

- The non-glance foreground process will load everything from the beginning of the PRG to the beginning of the resources section.

the-ninth said:

And I have some image resources only used in glance mode.

That's ok, just don't load those resources in non-glance mode, and you won't incur the memory hit. Resources don't use memory unless you load them.

The only exception is that there's a non-trivial memory cost between the following 2 situations (outside of memory used to load resources themselves): loading 0 resources and loading at least 1 resource. This due to the fact that if you load at least 1 resource, the resource table (not the resource data) is loaded into memory permanently. This can be a huge memory hit on older devices, if you have lots of resources (e.g. strings).

the-ninth said:

I'd like to write a simpler version of a class for glance mode, but don't want it to cost additional resources in foreground mode

This may not be ideal logistically speaking, but I think the optimal way to do this is to have a single class for both the glance and non-glance processes, and annotate the symbols required for the glance process with :glance. This does mean that you may have to split up some larger functions into 2 smaller functions (1 of which would not be included in the glance process), which would incur a small memory penalty for the non-glance process.

Thanks for all the explanations!

FlowState said:

which would incur a small memory penalty for the non-glance process.

Yes, so that is what I wanted to avoid. I wrote a few dedicated classes/functions for glances, which I do not need in the widget. Also the code of the glance view itself is relatively big in my case. So it would be nice to be able to not have this code being loaded in the widget.

Right now I am struggeling with out-of-memory errors in the widget on older devices.

FlowState said:

This due to the fact that if you load at least 1 resource, the resource table (not the resource data) is loaded into memory permanently. This can be a huge memory hit on older devices, if you have lots of resources (e.g. strings).

That may be one of the issues I am having. I have about 70 bitmap resources and about 25 properties.

The bitmap resources are mostly differently sized versions of the same images, and they are loaded based on how much data I need to fit onto the screen. So the number of bitmaps I actually load is small, but like you said the 70 are taking up space in the resource table anyway.

FlowState said:

This due to the fact that if you load at least 1 resource, the resource table (not the resource data) is loaded into memory permanently.

One question about that: does the resource id and file name I use impact the size of that resource table? Or are those translated to something more efficient by the compiler?