Joey Bloggs wrote: haven't got this far in .net yet but in java I had to implement Object Pools and an ObjectPoolManager to recycle objects. The costs in gc and performance where too high otherwise. You're certainly right in that there's a cost involved in using heap memory - in C++, Java as well as C#. If you have objects that are expensive to create and that you frequently need to allocate and deallocate such objects, pooling is a good idea in any language. I wouldn't do it until I saw it was a bottleneck though.

Joey Bloggs wrote: Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway) Certainly not! The CLR compiles to native code once and then re-uses the native code. It does not throw out any compiled code. Interpreted code is completely different from this. Something you don't mention is that managed code in fact can be much faster: - A managed execution environment can optimize on the specific machine you're running. - There are JVMs that re-compiles code that is frequently run and does more heavy optimizations on that code. - A managed execution environment can do cross-optimization over several assemblies, that weren't even known when designing the application. The above wouldn't be possible in a non-JITted environment. Before your next post, please spend some time learning how the CLR really works! Some good links are: Applied Microsoft .NET Framework Programming Writing High-Performance Managed Applications : A Primer (in the left columns you have several good articles as well) Articles by Jeffrey Richter MSDN Magazine

No, they will *start* much faster. That's completely different from *running* faster. A pre-jitted application is likely to run much slower, since the optimizations done by the JIT compiler won't take place. For details, see Jeffrey Richter's article about JIT Compilation and Performance - To NGen or Not to NGen.