{"id":14533,"date":"2026-09-24T10:32:22","date_gmt":"2026-09-24T10:32:22","guid":{"rendered":"https:\/\/playgama.com\/blog\/?p=14533"},"modified":"2026-09-24T10:32:22","modified_gmt":"2026-09-24T10:32:22","slug":"how-to-prevent-javascript-garbage-collection-pauses-using-ob","status":"publish","type":"post","link":"https:\/\/playgama.com\/blog\/business-faqs\/how-to-prevent-javascript-garbage-collection-pauses-using-ob\/","title":{"rendered":"How to prevent JavaScript garbage collection pauses using object pooling?"},"content":{"rendered":"

Preallocate a fixed array of reusable objects at load time, mark them active\/inactive instead of creating and discarding them, and reset their state on reuse. This avoids the per-frame allocations that trigger garbage collection pauses, which show up as frame hitches in bullets, particles and enemy spawns.<\/strong><\/p>\n

At a glance<\/h2>\n\n\n\n\n\n\n\n
Fact<\/th>\nValue<\/th>\nSource<\/th>\n<\/tr>\n<\/thead>\n
Main cause of GC pauses<\/td>\nPer-frame allocations<\/td>\n<\/td>\n<\/tr>\n
Common pooled objects<\/td>\nbullets, particles, enemies<\/td>\ndeveloper.mozilla.org<\/a><\/td>\n<\/tr>\n
Pool size strategy<\/td>\nfixed, preallocated array<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Object pooling stops GC pauses by never letting short-lived objects (bullets, particles, enemy instances) get created and thrown away every frame. Instead you preallocate a fixed array of them once, at load time, and reuse the same objects for the life of the game. Nothing new gets allocated during gameplay, so the garbage collector has nothing to sweep, and you avoid the frame hitches that show up as stutter on lower-end devices and mobile browsers.<\/p>\n

Playgama Bridge<\/a>, remember that the Bridge Storage docs specifically advise saving on meaningful events rather than every frame.<\/p>\n

Basic pattern:<\/p>\n

class BulletPool {\n constructor(size) {\n this.pool = Array.from({length: size}, () => ({active: false, x: 0, y: 0}));\n }\n spawn(x, y) {\n const b = this.pool.find(b => !b.active);\n if (!b) return null; \/\/ pool exhausted, skip or grow\n b.active = true; b.x = x; b.y = y;\n return b;\n }\n release(b) { b.active = false; }\n}<\/code><\/pre>\n
Key rules: never call new<\/code> or push to arrays inside your update loop; reset object state on reuse rather than recreating it; size the pool for your worst-case burst (peak bullets on screen), and either recycle the oldest entry or grow the pool once if you hit the limit instead of allocating ad hoc. Also avoid closures created per-frame and avoid .slice()<\/code>\/.map()<\/code> in hot loops – both allocate.<\/p>\n
What about engine-specific memory?<\/h2>\n
In Unity WebGL, pooling matters on the C# side; the JS bridge itself (Unity’s browser scripting interop<\/a>) is a separate concern from your gameplay object churn. Godot 4 web exports expose the JavaScriptBridge singleton for calling browser JS, but pooling logic still belongs in your game code, not the bridge layer.<\/p>\n
Sources<\/h2>\n