24 replies to this topic

[Miha]

I noticied out of memory issue again. It seems that it is affected by the work on other threads as well (which makes sense), but still, .NET MF reports that it has 20+ kB left, so it is puzzling. Additional question: will I have more memory if I deploy the release version of the program on the device (instead of debug build)? Regards, Miha.

[Chris Walker]

Hi Miha,

I noticied out of memory issue again. It seems that it is affected by the work on other threads as well (which makes sense), but still, .NET MF reports that it has 20+ kB left, so it is puzzling.

Some objects in memory are pinned in place. So you may have 20KB+ of memory left--but it may be in chunks which are smaller than the total amount of contiguous space your application is asking for. There may also be some larger temporary pieces of memory needed to complete an operation, such as string concatenation, and those will need contiguous chunks as well.

Additional question: will I have more memory if I deploy the release version of the program on the device (instead of debug build)?

The Visual Studio debugger takes several KB of memory. To demonstrate that, put the following line of code first in your application:

Debug.Print("freemem: " + Debug.GC(true));

Run your app from Visual Studio. Now stop your app, connect via MFDeploy, reboot your board, and Ping from MFDeploy. You'll now see a larger number

Chris

[Miha]

Some objects in memory are pinned in place. So you may have 20KB+ of memory left--but it may be in chunks which are smaller than the total amount of contiguous space your application is asking for. There may also be some larger temporary pieces of memory needed to complete an operation, such as string concatenation, and those will need contiguous chunks as well.

Yes, I understand that. It's just hard to debug, since OutOfMem errors are sporadic

The Visual Studio debugger takes several KB of memory. To demonstrate that, put the following line of code first in your application:

Debug.Print("freemem: " + Debug.GC(true));

Run your app from Visual Studio. Now stop your app, connect via MFDeploy, reboot your board, and Ping from MFDeploy. You'll now see a larger number

Thanks for the tip. So, this means that there is no difference between debug/release builds? Only if I deploy/debug it via VS vs. MFDeploy?

Regards,
Miha.

[H07R0D]

One thing that's saved me a lot of space has been to avoid any of the 'bigger' stream objects, and sticking with just FileStreams.

Opening a FileStream has the added benefit of not having to check for File.Exists thanks to the FileMode Enumeration. It takes care of appends/overwrites for you.
The only thing you'll have to watch is you're dealing with bytes, not strings, but that's really easy to handle too, with Encoding.UTF8.GetBytes().

For my Aquarium Controller, I was hitting memory problems all the time since it's running a web server, a task scheduler, and various plugins for sensor input/output.
Ditching Text and Stream writers saved lots of valuable space.

[Miha]

Thanks, I'll try that. I'm only writing a couple of settings to file, so doing it with FileStream is not going to be a problem.