Hi Tom, I understand your doubts; we had the same doubts more than ten years ago, when we considered switching embedded system programming to Java; Java has a similar garbage collection approach. But we did switch over, and soon we were glad we did because of the increased programmer efficiency and code robustness. The garbage collection concept is quite OK if you pay some attention to it. Of course you must (continue to) care about the number of objects you create; every object sooner or later must be retrieved to recycle the memory it was occupying. Switching an image processing application from C++ to C# should not be seen as an open invitation to turn every pixel into an object... Here are some examples that limit the object generation rate: 1. when performing complex string operations (say a number of concatenations), you will be better of using a StringBuilder. 2. short-lived objects, large or small, that only consume a limited number of CPU cycles in their life span, need special attention, to avoid the gc effort becoming noticeable. If you currently manage these objects yourself, you can continue to do this, by recycling them, rather than letting them fade away. I do not recommend you do this all the time, but when applied to a few classes at the heart of your application domain, it may prove quite useful. Of course these examples may seem like giving in on the advantages of C#, but that would be true only partially and locally. It is similar to general performance optimisation: in order to improve overall app performance, one must look for hot spots and then give in a bit to gain some (or a lot). Hope this may be helpful. :)
Luc Pattyn [My Articles] [Forum Guidelines]
