That said in theory being able to limit the duration of a GC call sounds like a good idea. While removing GC seems less optimal.

But that is a not a big deal as it might seem or at least, it’s not that worse than manual memory management.

I can already see so many programmers looking at that graph and thinking that they’re indeed right when they think that GC sucks and C/C++ memory management is the key…

I don’t think you’re right when you say that not allocating in runtime makes GC not useful. GC is NOT a tool to avoid memory leaks, is NOT a tool for lazy programmers that do not want to write a free here and there. In fact, even in C those problems are not problems, with a good debugging malloc leaks are an easy bug to solve (fragmentation is the real bitch).

GC is to make objects live across modules possible. In C++ in order to do that you write a RC system, and 99% of the games do that. GC is better than RC at solving that problem, that’s his strength, not the leaks thing…

As for the runtime cost… It can be high, but it’s important to note that even manual memory allocation/deallocation cost is high, and games usually avoid dynamic allocations in runtime, even without GC! That said, the situation is even worse, if you factor in the RC time, that as I said, most games use…

So in summary… GC has an overhead in runtime? True, but who cares, memory management overhead is anyway too high and unpredictable even without GC. What’s the advantage of GC then? It’s a better RC system! Why moving GC are cool? Mostly because you can avoid fragmentation, that’s the real problem!

Than again, I am a C programmer, and write C# like C++, and when all you have is a hammer, everything looks like a nail.

The other difference is that Python remains a dynamic language at its core, so even with JIT engines they do not match the performance of statically compiled languages like C# or UnityScript.

@Steve I thought quite a few people are using python now? Probably not as many as Lua, but then again Lua is utterly trivial to integrate and get up and running. I haven’t used much python myself, but the usual complaints I here are:
- tricky/time consuming to get properly integrated
- has some nasty performance cases
Are these fair? Is mono easier or better in these regards?

I must admit that I’m still not hugely fond of Python’s fixed source tabulation, but I can live with that given how much more mature and packed with features it is than so many alternatives.

I think it would be rather nice extension – possibility to allocate objects with “single frame” lifetime – collection then would be a simple pointer move at the end of the frame.

However protecting user from accessing destroyed object during the next frame could be tricky (at least with BoehmGC) – most probably that would require usage of proxy pointers or objects would have to store “timestamps” for sanity checks.

You should be able to do arrays without copying by either allocating a chunk of memory from the GC, or by allocating an array, pinning it, and using ‘UnsafeAddrOfPinnedArrayElement’. I have been using the second method but I haven’t done performance measurements. I could be totally wrong.

I spent a significant chunk of time putting the .NET/C interop stuff through its paces about a few months ago, and my findings were that there are lots of ways to do it, and many of them are bad to do. Being able to examine the IL code really helps with a lot of things I have found. I have also found that, if the API is causing excessive marshaling time, it may be needed to change the API.

As for comparing mono vs lua; they can’t be compared, one is a compiled system the other us an interpreter; If you want interpreter speeds, by all means use an interpreter and it will be a lot easier to port.

As for the structure representation, yes, there are ways of designing your structures and your marshalling to avoid any conversions. Send me email or post to mono-devel list and I will be happy to tell you how to do it based on your own structures
Finally, as I have suggested to Lucas and you guys, the silverlight profile has fewer cross dependencies and it works better with the mono linker. Our linked applications using the generics corlib are smaller than your hand chopped mscorlib and there is still a lot of room for improvement. The linker is the smarter way of working, as oppossed to the tedious and error prone approach thy you have use so far. I realize that “we need it fast and we need it today” gets in the way of using the smarter solution, but it has been entirely your choice.

On manual memory mangement: there is a partial solution, you need your objects to implement IDisposable and then call Dispose on them. It won’t take care of everything, but it will help. You can also allocate memory manualy using the Marshal class an release it yourself, it is useful in particular for large buffers.

Another trick that you can use to avoid the jittery GC is to enable incremental gc at runtime, I would you to try that and follow up with the results as it seems promising.

Keep up the great work!