views:

252

answers:

3

Hi,

Right now I'm experiencing lag spikes every 3-4 seconds where 500ms+ is spend on GCing.

Does anyone have some pointers on controlling the Mono GC? I.e. get it to collect n% of the memory instead of 100% while increasing the collection interval.

Thanks

+1  A: 

If its design is similar to the .NET GC (which I would assume is so), you probably can't. But then you shouldn't have to. The garbage collector knows better than you what's going on in the computer's memory.

I'd think the better way to deal with this would be to examine your own code. WHY are you allocating so much memory that there's so much collecting going on? Is the hardware you're running on adequate to handle the code's purpose? Would you possibly benefit from some disk caching scheme (since so much of this memory that's being allocated seems to be going away in short order)?

DannySmurf
I'm not creating any new objects. It's an underlying mono feature (continuations) that's acting up.
jameszhao00
+1  A: 

Mono's GC is the Boehm conservative, generation GC, which I don't believe has any of these controls.

Alex Gaynor
+1  A: 

I'm afraid that, in the absence of control over your GC implementation the only answer to such questions that will give you useful results is "Stop creating so many objects".

The specific answer to your specific need is your use of continuations.

Continuations in mono are of the stack copying variety. (assuming you are using the built in Tasklets implementation).

It appears that the mono compiler/JIT stores these copies in managed code, so use of continuations with a low ratio of work to yield is likely to lead to quite a bit of GC overhead. Thus your issues with the amount of GC time strongly suggest you are using co-routines in a manner where the implementation aspects outweigh the amount of time you spend in the actual coroutine by some margin.

If you are that dependent on continuations for performance you may want to consider going to a non portable alternative (since they aren't supported on the windows CLR this doesn't loose you much portability) in unmanaged code for that aspect of your system.

You may also be able to move to a enumeration based model making use of the (entirely portable) yield return constructs which would incur object creation only on the first call rather than on all yields which might be a net win. Obviously code would require rewriting and this is not going to perform as well if you are using nested constructs. For a guide to this see the section headed "C# Yield Statement in Mono" which is used in Unity.

ShuggyCoUk