3 replies to this topic

[sjmill01]

I've saw a post that said the Garbage collector can take 3ms to execute.

 

Are there any Coding Best Practices that helps minimize how long it takes?  For example, should you set variables to null before exiting a method?

 

Thanks,

Sean

[Mario Vernari]

Hello Sean.

Although you cannot avoid the garbage collection process, you may write the code in a way to minimize its duration.

There's nothing difficult behind the trick, you should think what's the goal of the GC: clean up the no more useful data from the heap (ram). Thus, you should favor the endless and the long-life objects, other than the create-and-destroy pattern. It's much closer to the C/C++ programming practices, I guess.

 

You may take a look at some functions of my repository.

http://cetdevelop.co...lpers.Format.cs

These functions aren't particularly complex, and they could be written in a shorter yet elegant way. However, there's a pretty decent attention about the GC and the efficiency. If you check the "ToHex" function, for instance, there's no string concatenation, which is very memory intensive. Instead, there's an initial estimation of the final string length, and everything will spin around a (fixed-size) char array. So, not only the performance is far better, but the GC overhead is irrelevant.

 

Please, note that a relevant GC activity could lead to an out of memory exception, due the very high fragmentation and the relative inability to release useless blocks of memory. That is, the reliability of your app is better when the GC is minimal.

 

Ciao.

[sjmill01]

Thanks!  Applying these practices took away the GC "Failed to Allocate xxx" messages upon compiling, so I have a little more trust in the stability of my program.  I'm trapping RC input and pulsing out PWM to motors and didn't want my robot to run over someone due to the GC kicking in.  I still have some "just in case" logic for bad pulse reads, though...just in case!

 

Thanks,

Sean

[chris9876]

Hi Mario, Hi Sean, it seems you have some experience with the GC and tighter memory. Can you give me some answers and hints to the GC Output. Is it an Output from .NET MF? or is the Output Netduinofirmware specific? Is it documented somewhere what each line means exactly? Is there a C#(.NET MF) function that specifies how much memory is free? .. to print out at runtime or respond to it in any C#-tech way? One question more: If you have a C# function witch returns Array(Byte)Data in e.g.: public static byte[] GetBytes(long value) { var array = new byte[8]; InsertValueIntoArray(array, 0, value); return array; } By the caller it looks like this: byte[] bx; do{ bx = GetBytes(longValue); . . } while(forever) What happens with the 8Byte receiving from GetBytes? Where do they go when I call GetBytes again and again and again....(where they are located(Heap?)...how can i destroy them?) Do you have some idea...thanks for Help(ich glaube ich steh gerade ordentlich auf der Leitung) Output from GC(like mentioned above): GC: 3msec 1482048 bytes used, 2712036 bytes available Type 0F (STRING ): 108 bytes Type 11 (CLASS ): 428244 bytes Type 12 (VALUETYPE ): 72 bytes Type 13 (SZARRAY ): 664968 bytes Type 03 (U1 ): 664056 bytes Type 04 (CHAR ): 276 bytes Type 07 (I4 ): 36 bytes Type 11 (CLASS ): 600 bytes Type 15 (FREEBLOCK ): 2712036 bytes Type 17 (ASSEMBLY ): 15252 bytes Type 18 (WEAKCLASS ): 48 bytes Type 19 (REFLECTION ): 24 bytes Type 1B (DELEGATE_HEAD ): 72 bytes Type 1D (OBJECT_TO_EVENT ): 312 bytes Type 1E (BINARY_BLOB_HEAD ): 262512 bytes Type 1F (THREAD ): 744 bytes Type 20 (SUBTHREAD ): 96 bytes Type 21 (STACK_FRAME ): 780 bytes Type 27 (FINALIZER_HEAD ): 106584 bytes Type 28 (MEMORY_STREAM_HEAD ): 36 bytes Type 29 (MEMORY_STREAM_DATA ): 396 bytes Type 31 (IO_PORT ): 468 bytes Type 34 (APPDOMAIN_HEAD ): 72 bytes Type 36 (APPDOMAIN_ASSEMBLY ): 1260 Bytes regards Christian