I'm having a strange stuttering issue in my game prototype. I use GC allocations wildly for the heck of it at the moment--with eventual plans to remove them.

However, I'm not positive it's the GC that's the problem, and if so, I want to know exact lengths of time and frequency.

Currently, the game will freeze for up to even half a second or more (but pretty rarely of 15+ seconds apart or more) but strangely... I'm using stopwatch's to track the logic and drawing code's elapsed times and ... those stopwatches don't appear to show the frozen time. Maybe my time code is incorrect somewhere but I need to be sure.

The hallmarks of GC are there because it "seems" to occur more often / worse when I'm low on RAM.

In LDC2, I saw import/core/memory.d -> gc.collect() which calls gc_collect (a C function)

However, adding a printf in there doesn't appear to print, so I'm guessing that gc.collect is only for users and not actually called by any internal lib functions? So my next thought is, to get a full source distribution, and recompile DMD or LDC2 from source after finding that C source file and adding a printf in there.

I doubt a single printf (or some static string equivalent without formatting overhead) would take that much time compared to a complete garbage collection so I don't think it would skew the results enough to useless. The big thing to check here is if these "freezes" are directly related to garbage collections, or some other oddity.

On 23/12/2017 11:06 AM, Chris Katko wrote:
> I'm having a strange stuttering issue in my game prototype. I use GC allocations wildly for the heck of it at the moment--with eventual plans to remove them.
> 
> However, I'm not positive it's the GC that's the problem, and if so, I want to know exact lengths of time and frequency.
> 
> Currently, the game will freeze for up to even half a second or more (but pretty rarely of 15+ seconds apart or more) but strangely... I'm using stopwatch's to track the logic and drawing code's elapsed times and ... those stopwatches don't appear to show the frozen time. Maybe my time code is incorrect somewhere but I need to be sure.
> 
> The hallmarks of GC are there because it "seems" to occur more often / worse when I'm low on RAM.
> 
> In LDC2, I saw import/core/memory.d -> gc.collect() which calls gc_collect (a C function)
> 
> However, adding a printf in there doesn't appear to print, so I'm guessing that gc.collect is only for users and not actually called by any internal lib functions? So my next thought is, to get a full source distribution, and recompile DMD or LDC2 from source after finding that C source file and adding a printf in there.
> 
> I doubt a single printf (or some static string equivalent without formatting overhead) would take that much time compared to a complete garbage collection so I don't think it would skew the results enough to useless. The big thing to check here is if these "freezes" are directly related to garbage collections, or some other oddity.

This isn't related to LDC.
Its just using extern(C) for its linkage abilities.

https://github.com/dlang/druntime/blob/master/src/gc/proxy.d#L90