• State Not Answered
  • Replies 11 replies
  • Subscribers 17 subscribers
  • Views 2324 views
  • Users 0 members are here
Options
Related

out of memory

Fsallstrom
over 4 years ago

I have developed a data field and I am really on the memory limit for some of the devices. Basically as soon as I add any more code/functionality to the data field I get "out of memory" in the sim (even one line of code may tip it over). I understand that memory available for data fields is restricted and the only way forward for me is to optimize memory usage of my data field.

On the Phoenix 5 Sim, I get peak usage 28.5kB, so clearly hitting the memory limit, but when I bring up the memory usage stats in the sim, the memory size does not add up to the 28.5kB. I'm using a background process, could it be that the memory used in background is not shown here?  

 

In order to optimize memory usage, would it make a big difference to move from layouts to dc.writes? I currently have many layouts, and I load a specific layout based on the obscurity flags and device type (with simple data field I could just let the system render with the proper font size, but this is a complex data field so I need to take care of that myself). It would add a lot of complexity to the code if I were to change to dc.writes, but if that will save me some memory it might be worthwhile, what are your thoughts? 

I am also loading a bitmap resource in runtime, from a list of approx 10 bitmaps. Each bitmap is approx 250 bytes. I only load one bitmap and not the entire list, to preserve as much memory as possible. Is there anything in terms of handling resource and bitmaps that I should think about in order to save memory? 

I store some user settings and other variables I need to share between the main process and background process, will objects stored in the object store also consume from the 28kB memory pool? and if so, is there any other approach that would be more efficient? 

Sorry for asking such open questions but wanted to see if some of you experienced developers have som tips and tricks for me. Many thanks in advance!

/Fredrik

  • 0 over 4 years ago in reply to jim_m_58
    jim_m_58 said:

    If you free up 50 bytes of code space in the background, you have 50 bytes more for the data field.

    Also, while the background runs on it's own, when it does the Background.exit(), the amount of data you pass impacts the data field.  If you return 500 bytes, in onBackgroundData, the DF uses 500 bytes, so you can free up some memory if you return 100 bytes instead of 500 for example.

    I think all of that is understood (see below), and none of it negates my original point that the background and main app don't share the same memory (in terms of process heap/stack or process memory limit).

    The fact that two containers have some of the same objects doesn't negate the fact that they're different containers and can have different sizes.

    Also, any code that is shared by both the background and main app will be obviously shown as part of the total in the memory viewer, and the OP was specifically asking about things that wouldn't show up in the memory viewer, when referring to the background process.

    Thanks for pointing out that the size of the data the background process returns has an impact on memory in the foreground app. TBH I thought that would be obvious, but it's worth pointing out explicitly.

    The reason I brought up the fact that they're separate processes  is because people have had the erroneous impression in the past that the background and main app were two threads in same process which can see the same global variables (for example).

    flowstate said:
    If your background process returns an object to the main process, seems like that could also cause a memory spike.

    flowstate said:
    The two processes share some of the same *code