Comment by pizlonator
11 days ago
Meh.
The stack scan is really fast. There's not a lot of logic in there. If you max out the stack height limit (megabytes of stack?) then maybe that means milliseconds of work to scan that stack. That's still not bad.
That's a very long time. Milliseconds of work is an entire frame update-render cycle in a modern game.
Would your modern game have a stack that is so deep that it brushes up against the stack height limit?
Probably not. Your game would be inches of stack away from crashing
You're missing the point, they're giving an example of an entire workload that fits into your technique's worst-case overhead. It's could be the right trade-off and rarely be hit, but that worst-case does sound bad.
6 replies →
Games don't tend to have very deep callstacks. And if a game cared about performance also wanted to use GC, it would probably try to run the GC at the end of a frame when there is little on the stack.
Yeah UE GC safepoints at end of tick where there is no stack. That’s a common trick in systems that have both GC and ticking.
To be fair, FUGC doesn’t currently let you do that. The GC runs in a separate thread and soft handshakes at various points, which cause your game thread to react at poll checks and exits that might not be at end of tick.
But I could add a feature that lets you to force handshake responses to be at end of tick! That sounds like a good idea
FUGC runs the GC in a separate thread and you don’t have a lot of control over when it interrupts.
Latency-sensitive programs like games are usually careful to avoid deep recursion.