<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 April 2014 06:56, via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think it would be useful to be able to mark structs as @nogc_alloc or something similar.<br>
<br>
Interpretation: this struct and any data directly reachable from it is guaranteed to not be GC allocated. Then a precise collector could avoid scanning those and pointers to them.<br></blockquote><div><br></div><div>Why wouldn't precise GC be able to do this anyway? It already has data about everything it scans. It can easily produce a 'don't bother scanning this' bit at the start of that data without programmer assistance?</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Even with @nogc threads for audio/visual real time computations the GC itself will have to get down to consistent < 50-200ms freezes to get fluid interaction for content computations.<br></blockquote><div><br></div><div>
50ms is 3 whole frames, 200ms is 12.5 frames! I thought you were a realtime programmer?</div><div>In a visual realtime app, the GC will only be acceptable when it will not interrupt for more than 1ms or so (and I consider that quite generous, I'd be more comfortable with < 500µs). Otherwise you'll lose frames anyway; if your entire world exists within 16ms slices, how can you budget the frame's usual workload around the GC interruption?<br>
</div><div>And what if the GC interrupts more than once per frame? What if you have very little free memory?</div></div></div></div>