• Chris Katko (27/27) Dec 23 2017 I'm having a strange stuttering issue in my game prototype. I use
• rikki cattermole (4/34) Dec 23 2017 This isn't related to LDC.

Chris Katko <ckatko gmail.com> writes:

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.

rikki cattermole <rikki cattermole.co.nz> writes:

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