Free memory in simulator vs real device difference – which to trust?

If you are looking at the number on the bottom line of the sim, that's the idle memory (your code isn't actually running).  Use "View Memory" to get better info, including peak memory.

In this case, in order to be able to compare sim vs real device, I use “System.println(System.getSystemStats().freeMemory).” to print the available free memory to debug window/log file. Normally I would indeed otherwise use the “view memory” screen.

I'd trust the sim.  The free memory can vary based on where you have the println.  Do the optimization in the sim, where you do have View Memory

Agree, ideally I should trust the sim … but I really need the – potential - extra free memory 

So, I did a new experiment, to figure out if I can trust and use more memory on the real device vs sim:

I allocated more and more memory in sim, using class global “var dummy = new[X]”. Increased X just enough to make the Data field App crash in sim due to running out of free memory. It crashed in onUpdate().

I then increased further the memory allocation, build the code, and downloaded to my fr645. And, on my real device, it ran just fine, no crash due to running out of free memory – not until I had allocated additionally 800+ bytes!! And, it crashed in compute(), not onUpdate(). So, btw, dynamic loading should actually be minimized in compute() over onUpdate(). I have made sure settings are all same-same. 

So, seem I can trust real world!? Why this discrepancy between sim and real device? And, again, this is a trend across multiple devices that I have tested on, not just fr645.

 Anyone with insights into why the sim seem so much more “conservative” ?

Not sure I can throw much more light on the matter, but I can confirm the sim is "conservative". My watchApp runs fine on the device (Fenix5) but crashes "out of memory" in the sim.

1. In my opinion is quite opposite. I haven't errors on sim but on device.

2. It's very difficult to manage memory because many operation is out of you e.g. settings and in many situation they produce a big peaks. So I estimate system peaks and  try to keep free memory  about 10kB to the limit.

Interesting! What type of App? Wonder if that makes a difference.

Mine is a data field where I for sure I cannot afford to have 10kb spare. I have in fact only a few hundred bytes free in sim - and I have never seen crashes due to memory in the field. 

But, I have also spend great effort on makin sure to manage dynamic loads. Ex: This line of code:

      var h = System.getDeviceSettings().screenHeight;

load temporarily an entire entire object of class Toybox.System.DeviceSettings into memory - which is many hundreds of bytes. So, calls like this I have in my initialization code.

The point about settings loading memory temporarily I have seen mentioned before. I'll investigate that further to see if that can make my App crash. 

I've mentioned about WF but it's connected to all. 10kB is deepened of  peaks in my case:

- background 3kB

- settings 4kB

- stacks 3kB

Run your application and see peaks and and you will know the limit of free memory. In my opinion the main check is settings so  if you have it and try to change properties without strange error (system not found) you are safe.

yes there are a few big object like getDeviceSettings 1kB so it's good to read it event on app.onstart() before view (the problem is if you read it often to check e.g. alarmCount).

Thankyou for the input - I'll experiment with change of settings next!