Not that I know of. There are a bunch of games that use &quot;arena allocators&quot; or &quot;per-frame allocators&quot;. Often, the game engine creates a bunch of objects during a frame of gameplay that it <i>knows</i> won&#x27;t be needed once that frame is done. There&#x27;s a clever strategy for managing that. When the game starts up, you allocate a big block of memory, the arena, and then set a pointer to the beginning of it.<p>To allocate an object, you just increment the pointer by the size of the object being allocated and return the previous value. In other words, you just hand out some bytes and move the pointer just past them.<p>When the frame is done, to &quot;free&quot; all of those objects... just reset the pointer. Done.<p>But, to your original question, it&#x27;s almost always a bad idea to run your GC every tick or some other high frequency like that. GCs spend a certain amount of time visiting objects that are still in use. Doing that work over and over and over again burns tons of cycles for no point. To get the best overall performance, you want to do as <i>few</i> GCs as possible to minimize that redundant work.<p>The problem then is that when you wait a long time, you end up having to a big, slow GC and long pauses like that are a problem. Incremental and concurrent GCs avoid long pauses and give you smoother results, at the expense of slightly lower overall performance. They get better latency but worse throughput.